SQLite

A defect in the in-memory journal logic can leave the read cursor for the in-memory journal in an inconsistent state, which can result in a segfault. No simple test case is (currently) available for this problem. One must make heavy use of the SAVEPOINT operation to make it happen.

This problem was discovered by Django testing.

The problem only comes up when the size of a savepoint journal (which is a multiple of 1028 bytes) is an exact multiple of the in-memory journal buffer size, which defaults to 1016 bytes on 64-bit machines and 1020 bytes on 32-bit machines. And even then, you have to do just the right sequence of SAVEPOINT operations to get the cursor to be reused.

The following scripts will segfault 64-bit builds of SQLite 3.12.0:

PRAGMA page_size=1024;
BEGIN;
CREATE TABLE t1(x INTEGER PRIMARY KEY, y TEXT);
WITH RECURSIVE c(x) AS (VALUES(1) UNION SELECT x+1 FROM c WHERE x<250)
INSERT INTO t1(x,y) SELECT x*10, printf('%04d%.800c',x,'*') FROM c;
SAVEPOINT one;
  SELECT count(*) FROM t1;
  WITH RECURSIVE c(x) AS (VALUES(1) UNION SELECT x+1 FROM c WHERE x<250)
  INSERT INTO t1(x,y) SELECT x*10+1, printf('%04d%.800c',x,'*') FROM c;
ROLLBACK TO one;
  SELECT count(*) FROM t1;
  SAVEPOINT twoB;
    WITH RECURSIVE c(x) AS (VALUES(1) UNION SELECT x+1 FROM c WHERE x<10)
    INSERT INTO t1(x,y) SELECT x*10+2, printf('%04d%.800c',x,'*') FROM c;
  ROLLBACK TO twoB;
RELEASE one;
COMMIT;

For 32-bit builds, change the two "250" constants to "251".

For some builds (depending on compile-time settings) it might be necessary to add

PRAGMA temp_store=MEMORY;

to the top of the test script in the previous comment.