SQLite Forum

Version 3.35.6 ??

Version 3.35.6 ??

(1) By anonymous on 2021-04-28 16:42:11 [source]

Version 3.36 appears to be planned for the end of june.

But in the timeline I have seen quite a lot of fixes since version 3.35.5 - and a few before that didn't even make it into 3.35.5.

How about a version 3.35.6 with those fixes before june?

(2) By Richard Hipp (drh) on 2021-04-28 17:59:38 in reply to 1 [link] [source]

Why don't you pull down the latest trunk source code and use it. That would give you all of the latest "fixes", plus it would help to find any other problems that we might have missed.

To put it another way: Become part of the solution!

(3) By anonymous on 2021-04-28 18:30:22 in reply to 2 [link] [source]

Why don't you pull down the latest trunk source code and use it.

Well ... actually I am already doing something like that. However I do not blindly use trunk but instead select a base-version and cherrypick fixes for a private branch. That works for me.

Then why am I asking this? Someone in my past kindly explained to me that the simple fact that I can do someting, does not mean that everyone else can. So I am asking not for myself, but for those who can not build a new version.

That would give you all of the latest "fixes" ...

Why are you quoting fixes? Aren't they? A lot are even marked as such in their comments.

(4) By Richard Hipp (drh) on 2021-04-28 18:59:12 in reply to 3 [link] [source]

They are pretty obscure. Many of them only cause problems (for example) if you compile with SQLITE_DEBUG then take an out-of-memory error at just the wrong moment while reading a database file with a specific kind of corruption and while in "PRAGMA writable_schema=ON" mode, or some such. They are generally not things that are likely to come up in practice.

For example, the "fix" checked in a few moments ago requires a database with a specific kind of corruption in the sqlite_schema table and that also contains a trigger on the corrupt table, and then the application needs to run an ALTER TABLE RENAME on that table. That causes an assertion fault on SQLITE_DEBUG builds, but appears to be harmless on release builds.

There have been some recent enhancements to the dbsqlfuzz fuzzer which have enabled it to find a whole bunch of new errors. None of the other multitude of third-pary fuzzers that run against SQLite regularly have been able to find any problems, which is evidence that the problems currently being found by dbsqlfuzz are relatively obscure. Dbsqlfuzz was only able to find them after the post-3.35 enhancements. I ran over 2 billion iterations of dbsqlfuzz prior to 3.35.0 with no new finds.

The find rate is slowing. The plan for 3.36.0 is to do a release once things settle down again.

(5) By ThanksRyan on 2021-04-29 02:12:02 in reply to 4 [link] [source]

There have been some recent enhancements to the dbsqlfuzz fuzzer

I was wondering what that was. I didn't know if it was something you and your team were running or external folks. Thanks for a link to the doc about it.

What exactly is this thing that looks like a hash: https://www.sqlite.org/src/info/ff3538ae37a02f4f

dbsqlfuzz 683913e98f54fe4f14e8dd11a48011f73bdca58d

Is that a private Fossil repo artifact/check-in?

Just curious...

(6) By Richard Hipp (drh) on 2021-04-29 10:42:07 in reply to 5 [link] [source]

What exactly is ... "dbsqlfuzz 683913e98f54fe4f14e8dd11a48011f73bdca58d"

The "683913e98f54fe4f14e8dd11a48011f73bdca58d" is the SHA1 of a libFuzzer-generated test case that demonstrates a problem. (libFuzzer keeps track of test cases using the SHA1 hash - the naming convention is their choice, not mine.) All of these "finds" are saved in a separate Fossil repository for dbsqlfuzz. The phrase "dbsqlfuzz 683913e98f54fe4f14e8dd11a48011f73bdca58d" in the check-in comment allows us to link an SQLite change to a specific dbsqlfuzz test case.

Many of these test cases eventually get loaded into the test/fuzzdata8.db database in the main SQLite repository, where they are rerun using the "fuzzcheck" test program with every "make test".

We also maintain a much larger private database containing tens of thousands of dbsqlfuzz-generated test cases. That database varies in size, but is usually about 100 to 150 MB. This larger test corpus is run periodically using -fsanitize. See item 14 on the release checklist.

(7) By ThanksRyan on 2021-04-29 16:28:58 in reply to 6 [link] [source]

You go above and beyond everything you do, even your explanations. Thank you for continuing to maintain and improve all of your projects. We all appreciate your hard work.