SQLite

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.

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.

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.