| Ticket Hash: | 51ae9cad317a1b609735f99c88168bbf3661feb7 | |||
| Title: | Database corruption by alternating writes from 3.7.0 and 3.6.23 | |||
| Status: | Fixed | Type: | Code_Defect | |
| Severity: | Critical | Priority: | Immediate | |
| Subsystem: | B-Tree | Resolution: | Fixed | |
| Last Modified: | 2010-08-04 11:40:07 | |||
| Version Found In: | 3.7.0 | |||
| Description: | ||||
If the same database file is alternately written by SQLite version 3.7.0
and version 3.6.23.1 (or earlier), database corruption can occur. The
failure scenario is this:
The corrupt is that the in-header-size field at offset 28 into the header ends up being set incorrectly. This field was always zero for SQLite versions 3.6.23.1 and earlier; it was introduced for the first time in version 3.7.0. Version 3.7.0 knows to only use the in-header-size if the change-counter at offset 24 matches the change-counter-copy at offset 92. And so normally, 3.6.23.1 and 3.7.0 can interact without problems. Step 2 in the failure scenario above causes the in-header-size field to be set incorrectly (because 3.6.23.1 changes the size of the database but does not update the in-header-size field). The database is still valid after step 2, though, since the change-counter-copy at offset 92 no longer matches the change-counter at offset 28. However, step 3 updates both the change-counter and change-counter-copy without correcting the in-header-size, resulting in database corruption. dan added on 2010-08-04 11:39:07: | ||||