View Ticket
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: (text/x-fossil-wiki)
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

drh added on 2013-04-11 18:34:03: (text/x-fossil-wiki)
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: (text/x-fossil-wiki)
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.