Fiddling around with the fuzzcheck I stumbled upon an odd segfault when requesting verbose output with --vv. It happens on fuzzdata8.db sqlid 699.

This is using the SQLite-ae9d7c9c92.zip source version:

$ ./fuzzcheck --sqlid 699 --result-trace -vv ../test/fuzzdata8.db
sqlid=699
BEGIN
PRAGMA writable_schema = on
PRAGMA foreign_keys = off
PRAGMA encoding = 'UTF-8'
PRAGMA page_size = '4096'
PRAGMA auto_vacuum = '0'
PRAGMA user_version = '0'
PRAGMA application_id = '0'
CREATE TABLE t1(a INTEGER PRIMARY KEY,b)
CREATE TABLE t2(x UNIQUE)
./fuzzcheck ../test/fuzzdata8.db (sqlid=699): segfault

This works ok on sqlid 700.

$ ./fuzzcheck --sqlid 700 --result-trace -vv ../test/fuzzdata8.db
sqlid=700
BEGIN
PRAGMA writable_schema = on
PRAGMA foreign_keys = off
PRAGMA encoding = 'UTF-8'
PRAGMA page_size = '4096'
PRAGMA auto_vacuum = '1'
PRAGMA user_version = '0'
PRAGMA application_id = '0'
PRAGMA writable_schema = off
COMMIT
Peak memory usages: 1.111696 MB
fuzzcheck: 0 errors out of 1 tests in 0.014 seconds
SQLite 3.51.0 2025-08-05 12:01:43 ae9d7c9c922bb241363aa690b42b9664c4ad6e76ed5ce474daf1ab44461bc6a3 (64-bit)

Digging down the call tree leads to sqlite3recover.c. Query result returns 0 for what's expected to be a string column. This zero then propagates further and trips in printf.

#4  0x000055555556bff5 in recoverWriteSchema2 (p=0x55555592bc88) at /home/tester/SQLite-ae9d7c9c92/ext/recover/sqlite3recover.c:1251
1251	        recoverSqlCallback(p, zSql);
(gdb) l
1246	  if( pSelect ){
1247	    while( sqlite3_step(pSelect)==SQLITE_ROW ){
1248	      const char *zSql = (const char*)sqlite3_column_text(pSelect, 1);
1249	      int rc = sqlite3_exec(p->dbOut, zSql, 0, 0, 0);
1250	      if( rc==SQLITE_OK ){
1251	        recoverSqlCallback(p, zSql);
1252	      }else if( rc!=SQLITE_ERROR ){
1253	        recoverDbError(p, p->dbOut);
1254	      }
1255	    }