Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/5cb3a6cd8648c1585a8bd47c8333c5e406476527 (Fixed sqlite fuzzer to use upstream version).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

I think this one might be due to our patch at https://cs.chromium.org/chromium/src/third_party/sqlite/patches/0002-Use-seperate-page-cache-pools-for-each-sqlite-connec.patch?g=0. The assert may just not take into account the new DEFINE.

I think it's probably best to just delete the assert. Should I create a new patch for that or try to modify the other patch?

Issue 906832 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d546c801e92b9ccb9214a8097b1113ffc4d3e98

commit 3d546c801e92b9ccb9214a8097b1113ffc4d3e98
Author: Victor Costan <pwnall@chromium.org>
Date: Tue Nov 20 18:19:14 2018

websql: Fix racy SQLite API usage in SQLiteStatement.

SQLiteStatement::GetColumn value currently uses sqlite3_column_value()
to retrieve a sqlite3_value*, and then uses other API calls to extract
information from the value.

The SQLite documentation [1, 2] states that sqlite3_column_value()
returns an "unprotected value", which should not be operated on
directly. When SQLite is compiled with multi-threading support (as
Chrome does), the incorrect usage triggers assets in SQLite.

This CL replaces the incorrect usage of sqlite3_value* with SQLite API
calls documented in [2] which are safe to use, inspired from
sql::Statement.

[1] https://www.sqlite.org/c3ref/value.html
[2] https://www.sqlite.org/c3ref/column_blob.html

Bug:  906396 
Change-Id: Ic8f7caac31c5be91113af576c020236aeb4106dc
Reviewed-on: https://chromium-review.googlesource.com/c/1343574
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609748}
[modify] https://crrev.com/3d546c801e92b9ccb9214a8097b1113ffc4d3e98/third_party/blink/renderer/modules/webdatabase/sqlite/sqlite_statement.cc

mpdenton@: I have one more CL lined up that should fix the asserts we're currently seeing. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c6d3a866083891cf6cd935091ea877fa507d14a2

commit c6d3a866083891cf6cd935091ea877fa507d14a2
Author: Victor Costan <pwnall@chromium.org>
Date: Tue Nov 20 18:41:23 2018

sqlite: Use SQLite's API for getting per-database page pools.

Chrome currently carries a SQLite patch at
0002-Use-seperate-page-cache-pools-for-each-sqlite-connec.patch
which forces per-database (technically, per-connection) page cache
pools. Asides from adding to our maintenance burden, the patch breaks an
assert() in SQLite's code, suggesting that it doesn't work as intended
anymore.

Fortunately, SQLite has a few supported ways of specifying whether
database connections use private page cache pools or a central pool. The
most convenient method for Chrome is the SQLITE_OPEN_PRIVATECACHE flag
on sqlite3_open_v2() [1].

This CL does the following:

1) Removes the SQLITE_SEPARATE_CACHE_POOLS build flag, which activates
   Chrome's page cache pool patch. The patch (which becomes inert when
   this CL lands) shall be removed from our SQLite version in a
   follow-up CL, after this CL sticks.
2) Removes the SQLITE_ENABLE_MEMORY_MANAGEMENT build flag. This flag is
   incompatible with private page cache pools, because it enables the
   sqlite3_release_memory() function [2], which assumes a centralized
   (shared) page cache pool [3]. Chrome doesn't use
   sqlite3_release_memory() today, so the flag is unnecessary. If we
   want to trim SQLite caches in response to memory pressure, we can
   still use sqlite3_db_release_memory() [4] and track all the open
   connections ourselves.
3) Adds the SQLITE_OPEN_PRIVATECACHE flag to our invocation of
   sqlite3_open_v2().

[1] https://www.sqlite.org/c3ref/open.html
[2] https://www.sqlite.org/c3ref/release_memory.html
[3] https://www.sqlite.org/sharedcache.html
[4] https://www.sqlite.org/c3ref/db_release_memory.html

Bug:  906396 
Change-Id: Ib3b08b26364ad86d173111fc4e554bd07bd91aa1
Reviewed-on: https://chromium-review.googlesource.com/c/1343789
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609754}
[modify] https://crrev.com/c6d3a866083891cf6cd935091ea877fa507d14a2/sql/database.cc
[modify] https://crrev.com/c6d3a866083891cf6cd935091ea877fa507d14a2/third_party/blink/renderer/modules/webdatabase/sqlite/sqlite_file_system.cc
[modify] https://crrev.com/c6d3a866083891cf6cd935091ea877fa507d14a2/third_party/sqlite/BUILD.gn

The CL above should make the assert go away. Asked clusterfuzz to check if this still reproduces.

ClusterFuzz has detected this issue as fixed in range 609753:609755.

Detailed report: https://clusterfuzz.com/testcase?key=6474333779918848

Fuzzer: libFuzzer_sqlite3_ossfuzz_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: ASSERT
Crash Address: 
Crash State:
  pcache1.separateCache==0
  pcache1AllocPage
  pcache1FetchStage2
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=608964:608970
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=609753:609755

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6474333779918848

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 6474333779918848 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.