SQLite

The final INSERT in the script below reports that the database is corrupt (SQLITE_CORRUPT) and aborts. Subsequent analysis shows no database corruption.

PRAGMA page_size=512;
CREATE TABLE t1(x INTEGER PRIMARY KEY, y);
INSERT INTO t1 VALUES(1,randomblob(400));
INSERT INTO t1 VALUES(2,randomblob(400));
INSERT INTO t1 SELECT x+2, randomblob(400) FROM t1;
INSERT INTO t1 SELECT x+4, randomblob(400) FROM t1;
INSERT INTO t1 SELECT x+8, randomblob(400) FROM t1;
INSERT INTO t1 SELECT x+16, randomblob(400) FROM t1;
INSERT INTO t1 SELECT x+32, randomblob(400) FROM t1;
INSERT INTO t1 SELECT x+64, randomblob(400) FROM t1 WHERE x<10;
CREATE TRIGGER r1 AFTER INSERT ON t1 WHEN new.x=74 BEGIN
  DELETE FROM t1;
  INSERT INTO t1 VALUES(75, randomblob(400));
  INSERT INTO t1 VALUES(76, randomblob(400));
END;
INSERT INTO t1 VALUES(74, randomblob(400));

The problem occurs because the INSERT operation leaves its cursor open, though marked CURSOR_INVALID, while holding a reference to a second-level page of the btree. When the trigger fires it deletes content out from under this cursor, which is normally OK since the cursor is invalid. However, during the second INSERT inside the trigger, when a page is removed from the freelist to hold the new content, that page is checked to make sure it is unreferenced. This check fails since the invalid INSERT cursor is still holding a reference to the page. That reference makes it appear as if the page was on the freelist and in a btree at the same time and so an SQLITE_CORRUPT error is thrown. However, the page is not really on the btree since the cursor that is referencing it is marked CURSOR_INVALID.

This problem has existing in the code since late 2009. It is very difficult to hit, however (which helps to explain why it has gone undetected until now). The problem is very sensitive to the specific constants used in the script shown above.