SQLite: View Ticket

2014-12-05
15:31		The KeyInfo cache must be cleared before closing the btree, not after. Revised fix for ticket [e4a18565a36884b00edf]. (check-in: 7ed3346e user: drh tags: trunk)
15:25		The KeyInfo cache must be cleared before closing the btree, not after. Revised fix for ticket [e4a18565a36884b00edf]. (check-in: 48529508 user: drh tags: branch-3.8.7)
14:51		When closing a (shared-cache) database connection, be sure to clear out all KeyInfo objects cached on Index objects. Fix for ticket [e4a18565a36884b00edf]. (check-in: b7905b8c user: drh tags: branch-3.8.7)
14:44		• Fixed ticket [e4a18565]: Stale KeyInfo object used in shared-cache mode plus 5 other changes (artifact: 002412e9 user: drh)
14:44		When closing a (shared-cache) database connection, be sure to clear out all KeyInfo objects cached on Index objects. Fix for ticket [e4a18565a36884b00edf]. (check-in: adca7688 user: drh tags: trunk)
14:36		Add code to check the validity of CollSeq objects during runtime. This code was not able to detect anomalies such as came up as a result of ticket [e4a18565a36884b00edf66541f38c693827968ab] so it is put into a branch for historical reference, with the intent of leaving it out of trunk. (Closed-Leaf check-in: 68b23c3d user: drh tags: collseq-checking)
14:07		Test case demonstrating the problem described by ticket [e4a18565a36884b00edf]. (check-in: ffea3e90 user: drh tags: fix-stale-keyinfo-cache)
05:38		When closing a (shared-cache) database connection, be sure to clear out all KeyInfo objects cached on Index objects. Proposed fix for ticket [e4a18565a36884b00edf]. (check-in: 651ed97d user: drh tags: fix-stale-keyinfo-cache)
04:45		• New ticket [e4a18565] Stale KeyInfo object used in shared-cache mode. (artifact: 45f4b5d2 user: drh)

Ticket Hash:	e4a18565a36884b00edf66541f38c693827968ab
Title:	Stale KeyInfo object used in shared-cache mode
Status:	Fixed	Type:	Code_Defect
Severity:	Critical	Priority:	Immediate
Subsystem:	Unknown	Resolution:	Fixed
Last Modified:	2014-12-05 14:44:58
Version Found In:	3.8.5
User Comments:
drh added on 2014-12-05 04:45:14: The sqlite3KeyInfoOfIndex() routine (here) can return a stale KeyInfo object in shared cache mode. Scenario: Two open database connections (A and B) on the same cache The shared pIdx object is holding a KeyInfo object for A Connection A closes. Connection C opens, and by (bad) luck is allocated the same database connection pointer as A had. Connection C now tries to get a KeyInfo object for index pIdx but is handed the stale one from A. The KeyInfo object itself is ref-counted and so it is still live. But the KeyInfo points to CollSeq objects within the old A connection that are now dead and have been freed. This problem appears to have been introduced by check-in [c80e229dd9c1230ab] on 2013-11-07, which first appeared in SQLite version 3.8.2.