|
2013-04-12
| ||
| 13:53 | Fix the xCheckReservedLock() method on the windows VFS so that it cannot return a false positive when two or more processes use it at the same time on the same file. Ticket [7ff3120e4fa54abb55]. Update to version 3.7.16.2. (check-in: 67b3c0ef user: drh tags: sessions) | |
| 12:09 | • Fixed ticket [7ff3120e]: Recovery race condition leads to database corruption on Windows plus 4 other changes (artifact: b25ed2ca user: drh) | |
| 12:02 | • Ticket [7ff3120e]: 3 changes (artifact: 93a2d831 user: drh) | |
|
2013-04-11
| ||
| 19:04 | Increase the version number to 3.7.16.2 and cherrypick the fix for ticket [7ff3120e4fa54abb55]. This check-in is a release candidate. (check-in: 86f26f91 user: drh tags: branch-3.7.16) | |
| 18:34 | • Ticket [7ff3120e] Recovery race condition leads to database corruption on Windows status still Open with 6 other changes (artifact: 55e07771 user: drh) | |
| 18:28 | Fix the xCheckReservedLock() method on the windows VFS so that it cannot return a false positive when two or more processes use it at the same time on the same file. Ticket [7ff3120e4fa54abb55] (check-in: dd3510bb user: drh tags: trunk) | |
| 18:04 | • New ticket [7ff3120e] Recovery race condition leads to database corruption on Windows. (artifact: cc324cdb user: drh) | |
| Ticket Hash: | 7ff3120e4fa54abb551b1b7d1bc3835604e8b879 | |||
| Title: | Recovery race condition leads to database corruption on Windows | |||
| Status: | Fixed | Type: | Code_Defect | |
| Severity: | Critical | Priority: | Immediate | |
| Subsystem: | VFS | Resolution: | Fixed | |
| Last Modified: | 2013-04-12 12:09:20 | |||
| Version Found In: | ||||
| User Comments: | ||||
|
drh added on 2013-04-11 18:04:38:
The xCheckReservedLock() method on the windows VFS can sometimes return a false positive, if two different processes call it on the same file at the same time. This leads one of the processes (the one that got the false positive) to believe that the other process is taking care of recovering from a prior crash. That process might then write into the database without first running recovery, leading to corruption. To see this occur, compile and run the "mptester" utility with the mptest/crash01.test script many times on a fast multi-core win8 machine using check-in [663f04bd48bc6f3022] and you will eventually get integrity_check failures. drh added on 2013-04-11 18:34:03: This bug appears to have been inserted by check-in [61360ca6ca3448477] - the enhancements to the windows system interface that allowed SQLite to work with WinRT. The bug first appeared in release 3.7.13. We have not observed an occurrence of this bug in the wild. The problem was found during internal testing. drh added on 2013-04-12 12:02:12: Further analysis shows that this race condition is not new but has in fact existed in the code since SQLite 3.0.0, 2004-06-18. | ||||