| 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 10.57 years ago |
Created: |
2014-12-05 04:45:14 10.57 years ago |
| Version Found In: | 3.8.5 | ||
| User Comments: | ||||
drh added on 2014-12-05 04:45:14:
(text/x-fossil-wiki)
The sqlite3KeyInfoOfIndex() routine ([/artifact/67bb05b1077?ln=4192,4199|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.
| ||||