commit	2b68069dbe04142c690364e9f4755eb7b426024a	[log] [tgz]
author	Greg Thompson <grt@chromium.org>	Thu May 15 14:54:17 2025
committer	Copybara-Service <copybara-worker@google.com>	Thu May 15 15:02:18 2025
tree	44a7a8a8ee426f4356796d3f5221e75f1cca30ab
parent	6663699a0dda4b1d29bc14d38530387ba9c52144 [diff]

Roll src/third_party/sqlite/src/ 8a22b25ad..0a1397d27 (19 commits)

https://chromium.googlesource.com/chromium/deps/sqlite.git/+log/8a22b25ad724..0a1397d27470

$ git log 8a22b25ad..0a1397d27 --date=short --no-merges --format='%ad %ae %s'
2025-05-13 grt Amalgamations for release 3.49.2
2025-05-07 Version 3.49.2
2025-05-06 Fix a bug in the NOT NULL/IS NULL optimization that can cause invalid data to be used for a column if that column has a CHECK constraint that includes the NOT NULL or IS NULL operator.
2025-04-16 Correctly handle the case of a multi-column UNIQUE constraint that contains the ROWID as one of it columns, and then the columns of that UNIQUE are used in a row-value IN operator as a WHERE clause constraint.
2025-04-04 stephan Correct a makefile var name type in the configure script, introduced in [8830f86335].
2025-04-04 stephan Improve --all flag handling so that combinations of (--all --disable-FEATURE) and (--disable-all --FEATURE) work more intuitively. Add missing handling of the --fts3 flag (it was accepted but ignored before). Partial merge of [26ef0ff4bfbb], minus proj.tcl changes.
2025-04-04 stephan Account for the Mac-specific -install_name linker flag. See [forum:5651662b8875ec0a|forum post 5651662b8875ec0a].
2025-03-22 Fixes for two problems with the generate_series() table-valued function.
2025-03-18 Fix two obscure logic problems that cause incorrect answers, found by a third-party fuzzer.
2025-03-10 Disable the [d1ba200234f40b84|count-of-view optimization] if any subquery is DISTINCT, as the optimization does not work in that case.
2025-03-10 Fix the build by rerunning test/mkpragmatab.tcl.
2025-02-28 stephan Bring the autosetup-related bits up to par with trunk.
2025-02-28 stephan Strive to make sorts stable in the mkpragmatab.tcl build script, so that we get consistent amalgamations regardless of platform. [forum:/forumpost/c9914addebf3da51|Forum thread c9914addebf3da51].
2025-02-25 stephan Configure script cosmetics: emit the host/build system info before the directory info.
2025-02-25 stephan Diverse configure tweaks to better support package maintainers on the unix-on-windows environments like msys2, cygwin, and mingw, based largely on feedback in forum posts [forum:e6cf2bbb70da2922|e6cf2bbb70da2922] and [forum:828fdfe9041fd725|828fdfe9041fd725].
2025-02-21 stephan configure: in several places where support for -Wl,... linker flags are checked, ensure that the check invokes the linker (not just the compiler) to avoid false positives. This allows us to remove the AIX-specific handling and --disable-rpath bits added in [a15e0f680], as well as make several similar checks more robust.
2025-02-20 stephan Bump VERSION to 3.49.2.
2025-02-20 stephan configure: automatically fail the check for rpath on AIX systems and provide a --disable-rpath flag as a fallback for use on platforms which pass the configure-time rpath check but then fail at link-time. Based on discussion in [forum:ae5bd8a84b|forum thread ae5bd8a84b].
2025-02-20 stephan Fix autoconf bundle to honor the --disable-static and --disable-shared flags, as reported in [forum:ae5bd8a84b|forum post ae5bd8a84b]. Problem introduced in 3.49.0.

Created with:
roll-dep src/third_party/sqlite/src --update-readme

Fixed: 415397143
Change-Id: I4adb08f6dd403ef6c35de4509a118075309d7b90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6540287
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Reviewed-by: Etienne Bergeron <etienneb@chromium.org>
Auto-Submit: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1460715}
NOKEYCHECK=True
GitOrigin-RevId: 5327059b598732d5f4e1efc10e686fe73c70f7e2

README.chromium[diff]

1 file changed

tree: 44a7a8a8ee426f4356796d3f5221e75f1cca30ab

README.md

Chromium SQLite.

This is the top folder for Chromium's SQLite. The actual SQLite source is not in this repository, but instead cloned into the src directory from https://chromium.googlesource.com/chromium/deps/sqlite.

The directory structure is as follows. Files common to all third_party projects (ex. BUILD.GN, OWNERS, LICENSE) are omitted.

src/ The Chromium fork of SQLite (cloned via top level DEPS file).
scripts/ Scripts that generate the files in the amalgamations in src/.
sqlite.h The header used by the rest of Chromium to include SQLite. This forwards to src/amalgamation/sqlite3.h
fuzz/ Google OSS-Fuzz (ClusterFuzz) testing for Chromium's SQLite build.

Amalgamations

SQLite amalgamations are committed to the SQLite Chromium repository (in src), but are created by a script that lives in the Chromium repository. This is because the configuration variables for building and amalgamation generation are shared.

There are two amalgamations:

//third_party/sqlite/src/amalgamation is shipped, tested, and Fuzzed by Chromium.
//third_party/sqlite/src/amalgamation_dev is not distributed or tested by Chromium. It is used for some developer tools (either only for local development, or only on trusted input).

//third_party/sqlite/src repository.

CLs in this repository cannot be submitted through the commit queue (ex. CQ+2), because there is no commit queue / try bot support for this repository. Please use the “Submit” button (in Gerrit's 3-dot menu on the top right) to submit CLs in this repository instead.

Playbook

Upgrade to a new SQLite release.

SQLite should be upgraded as soon as possible whenever a new version is available. This is because new versions often contain security and stability improvements, and frequent upgrades allow Chromium to have minimal cherry-pick diffs when requesting investigation for SQLite bugs discovered by Chromium Fuzzers. New versions may be viewed here, and bugs for these upgrades may look like this example.

Historically, Chromium fuzzers often find issues within 2 weeks after upgrading to new SQLite versions. Avoid upgrading SQLite within 1-2 weeks of a Chromium branch point to allow fuzzers time to run. However, if the new SQLite release contains known security or stability fixes, upgrade once available and monitor fuzzers more closely.

SQLite version upgrades tend to be extremely large changes (example), for which the diffs are not possible to thoroughly review.

Note SQLite tags all releases version-<release number>, e.g. version-3.40.0. The Chromium project prefixes all tags/branches with “chromium-”, e.g. chromium-version-3.40.0.

Create new release branch
Create the branch at Gerrit/branches. The branch name should look like chromium-version-3.40.0 and the initial revision will look something like refs/tags/upstream/version-3.40.0.
Note: To create a release branch, you must be listed as a member in the sqlite-owners Gerrit group

Checkout the new Chromium release branch.

Get the version from the README.chromium.

cd third_party/sqlite/src  # from //chromium/src
git fetch origin
export VERSION=3.40.0
git checkout -b chromium-version-$VERSION \
    --track origin/chromium-version-$VERSION

Generate and commit the SQLite amalgamations.

./../scripts/generate_amalgamation.py
git add amalgamation amalgamation_dev
git commit -m "Amalgamations for release $VERSION"

Run local tests.
Follow steps in Running Tests below to execute all verifications and tests.
Upload the new release branch for review.
```
git cl upload
```
Roll the Chromium DEPS file.
Once review above has merged:
1. Roll the chromium/src/DEPS file to reference that new commit hash.
```
roll-dep src/third_party/sqlite/src --roll-to <git hash of merged CL>
```
2. Update the version in //third_party/sqlite/README.chromium. Amend the commit created by roll-dep above.

Cherry-pick unreleased commit from SQLite.

Sometimes critical fixes land in SQLite's master, but are not yet in a release. This may occur when other SQLite embedders find critical security or stability issues that SQLite authors then fix, but are often detected by Chromium ClusterFuzz as well.

If you're triaging a ClusterFuzz bug, an internal playbook on how to triage and fix ClusterFuzz bugs is available at go/sqlite-clusterfuzz-bug-process.

If changes need to be brought into the current release branch, please do the following:

Checkout the current release branch.

Get the version from the README.chromium.

export VERSION=3.40.0
cd third_party/sqlite/src  # from //chromium/src
git checkout -b chromium-version-$VERSION \
  --track origin/chromium-version-$VERSION

Cherry-pick the change
Git can be used to cherry pick upstream changes into a release branch but the sqlite_cherry_picker.py script is preferred. This script automates a few tasks such as:
- Identifying the correct Git commit hash to use if given the Fossil commit hash.
- Automatically calculating Fossil manifest hashes.
- Skipping conflicted binary files.
- Generating the amalgamations.
Cherry-pick the commit:
```
../scripts/sqlite_cherry_picker.py <full git commit hash>
```
If there is a conflict that the script cannot resolve then, like git cherry-pick, the script will exit and leave you to resolve the conflicts. Once resolved run the script a second time:
```
../scripts/sqlite_cherry_picker.py --continue
```
If you have access to the SQLite fossil commit hash, and would like to map this to the corresponding git hash, you can use GitHub search. As SQLite‘s git repository’s commits include the fossil hash, you can search for the fossil hash, using the following query with the fossil commit hash appended (example search): https://github.com/sqlite/sqlite/search?type=commits&q=
If the cherry-picking script is unable to cherry-pick a commit, like in https://crbug.com/1162100, manually apply the change from a SQLite or git, in //third_party/sqlite/src's files modified in the SQLite tracker, like at https://sqlite.org/src/info/a0bf931bd712037e. From there, run ../scripts/generate_amalgamation.py to propagate these changes over to the amalgamation files. sqlite_cherry_picker.py should generally be preferred, as it updates hashes and simplifies tracking.
Run local tests.
Follow steps in Running Tests below to execute all verifications and tests.
Upload cherry-picked change (with amalgamations) for review.

If the relevant bug is a security bug, make sure that the reviewers are cc‘ed. Otherwise, they may not know what/why they’re reviewing.

```sh
git cl upload
```

Update the Chromium DEPS file.
Once review above has merged, roll the chromium/src/DEPS file to reference that new commit hash.
```
roll-dep src/third_party/sqlite/src --roll-to <git hash of merged CL>
```

Running Tests

Build all desktop targets:

Check that extract_sqlite_api.py added “chrome_” to all exported symbols. Only “_fini” and “_init” should be unprefixed, but are conditionally exported by the linker and may be omitted.

autoninja -C out/Default
nm -B out/Default/libthird_party_sqlite_chromium_sqlite3.so | cut -c 18- | sort | grep '^T'

Running unit tests

out/Default/sql_unittests

Running SQLite's TCL test suite within the Chromium checkout.

This is one of the SQLite test suites. They take approximately 3 minutes to build and run on a fast workstation.

Note: Tests currently fail both locally and on Chromium release branches. They fail on release branches because some tests rely on SQLite databases (binary files) which are committed to the source and are likely not merged down when cherry picked. It is safe to ignore these errors which should be reasonably easy to identify based on the cherry picked upstream changes. Until these tests are fixed, it is safe to ignore these tests when running SQLite test suites.

cd third_party/sqlite  # from //chromium/src
./scripts/generate_amalgamation.py --testing
make --directory=src test | tee /tmp/test.log

Show tests with errors:

egrep 'errors out of' /tmp/test.log

Show broken tests:

egrep 'Failures on these tests:' /tmp/test.log

Broken tests will also show lines ending in “...” instead of “... Ok”.

When done, clean up the SQLite repository:

cd src
make clean
git clean -i  # and delete everything
rm -rf testdir
git checkout amalgamation/sqlite3.c
git checkout amalgamation_dev/sqlite3.c

Bisect SQLite

When diagnosing the cause of an issue found in a fuzzer issue or while bringing up SQLite, you may want to bisect the SQLite repo.

To find the SQLite commit that introduced an issue the scripts/repro_tool.py can be used in combination with git bisect run.

For example, given a good commit of 9e45bccab2b8, a bad commit of c12b0d5b7135, and a reproduction sql file repro.sql, running the following will pinpoint the commit that introduced the failure:

cd src
git bisect start c12b0d5b7135 9e45bccab2b8
git bisect run ../scripts/repro_tool.py repro.sql

The reproduction file can be omitted if it is a build error. --should_build can be passed to repro_tool.py if the issue is not a build error and we don't want to continue bisecting if a build does fail.

See scripts/repro_tool.py --help for more information.