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:
(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.

This page was generated in about
0.02s by
Fossil version 1.37 [814dfd5a9c] 2016-12-08 20:03:09