SQLite

View Ticket
Login
2011-10-29
15:29
Add a test for [48f29963] that does not depend on FTS. (check-in: fb15f545 user: dan tags: trunk)
11:54 Ticket [48f29963] Crash in SAVEPOINT within a transaction that writes to then drops an FTS table status still Closed with 1 other change (artifact: 0a2d10e3 user: dan)
11:46 Closed ticket [48f29963]. (artifact: 0d0b3bfb user: dan)
11:43
Avoid attempting to call savepoint related methods on deleted sqlite3_vtab objects. Fix for [48f299634a]. (check-in: 3565fcf8 user: dan tags: trunk)
11:36 Ticket [48f29963] Crash in SAVEPOINT within a transaction that writes to then drops an FTS table status still Open with 3 other changes (artifact: a6be4fd0 user: dan)
11:31 New ticket [48f29963]. (artifact: e054b682 user: dan)

Ticket Hash: 48f299634acb013ba05730b8d86bb029fc4372f2
Title: Crash in SAVEPOINT within a transaction that writes to then drops an FTS table
Status: Closed Type: Code_Defect
Severity: Important Priority: Immediate
Subsystem: Virtual_Machine Resolution: Fixed
Last Modified: 2011-10-29 11:54:59
Version Found In: 3.7.8
Description:
The following script causes a crash:
CREATE VIRTUAL TABLE f1 USING fts3;
BEGIN; 
  INSERT INTO f1 VALUES('a b c');
  DROP TABLE f1;
  SAVEPOINT one;

This is not an FTS specific problem. It can occur using any virtual table implementation that sets sqlite3_module.iVersion>=2 (i.e. one that requires callbacks for SAVEPOINT, ROLLBACK TO and RELEASE commands).

To reproduce this, the user must open a transaction, write to the virtual table and then DROP it. Thereafter, any SAVEPOINT, ROLLBACK TO or RELEASE command within the transaction that is not a no-op will cause a crash.


dan added on 2011-10-29 11:46:05:
Fixed here: [3565fcf898].


dan added on 2011-10-29 11:54:59:
First appeared in version 3.7.7.