SQLITE_DEBUG, DSQLITE_DEFAULT_MEMSTATUS=0, SQLITE_MEMDEBUG triggers assertion failure
(1) By 0xjnml on 2020-08-20 10:34:47 [link]
Not sure if this is a real memory corruption of just an "illegal" combination of compile time options. In the later case it should be probably documented and/or detected and rejected. --- SQLite-d8e47382$ cat bug.sh make distclean ./configure CFLAGS="-DSQLITE_DEBUG -DSQLITE_DEFAULT_MEMSTATUS=0 -DSQLITE_MEMDEBUG" make testfixture cd test ../testfixture permutations.test extraquick corrupt2.test SQLite-d8e47382$ ./bug.sh rm -f *.lo *.la *.o sqlite3 libsqlite3.la ... corrupt2-1.1... Ok corrupt2-1.2... Ok corrupt2-1.3... Ok corrupt2-1.4... Ok corrupt2-1.5... Ok corrupt2-2.1... Ok corrupt2-3.1... Ok corrupt2-4.1... Ok corrupt2-5.1... Ok corrupt2-6.1... Ok corrupt2-6.2... Ok testfixture: sqlite3.c:24015: sqlite3MemsysGetHeader: Assertion `pU8[nReserve]==0x65' failed. ./bug.sh: line 5: 24738 Aborted (core dumped) ../testfixture permutations.test extraquick corrupt2.test SQLite-d8e47382$
(2) By Dan Kennedy (dan) on 2020-08-20 11:08:19 in reply to 1
Thanks for reporting this. Turns out it's a bug in test code only. Now fixed here: [](https://sqlite.org/src/info/3c5e63c22ffbfeb6) If you need to run the test suite without these options and you can't update, edit file test/corrupt2.test and change the only occurrence of "010000000" (9 digits) to "01000000" (8 digits). Dan.
(3) By 0xjnml on 2020-08-20 11:36:50 in reply to 2 [link]
I'm happy to confirm the linked commit fixed the issue, thank you.