View Ticket
Not logged in
Ticket UUID: 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.