993556 - SQLite crash in walIndexTryHdr due to Windows EXCEPTION_IN_PAGE_ERROR exception

Status: NEW

(Core :: SQLite and Embedded Database Bindings, defect, P5)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I have a flaky docking station. Because of said flakiness, sometimes when I sit down to work I find that some peripherals have disconnected overnight.

Today's victim was my external HDD. I was running Firefox with a test profile that was hosted on that drive. Since the connection to that drive had been severed, when SQLite went to do some memory-mapped I/O on a file that was located on that drive, Windows raised an EXCEPTION_IN_PAGE_ERROR exception that was unhandled, resulting in a crash.

nss3!walIndexTryHdr+0x2e
nss3!walIndexReadHdr+0x31
nss3!sqlite3WalBeginReadTransaction+0x5b
nss3!pagerBeginReadTransaction+0x2a
nss3!sqlite3PagerSharedLock+0x28f
nss3!lockBtree+0x10
nss3!sqlite3BtreeBeginTrans+0xad
nss3!sqlite3VdbeExec+0x232d
nss3!sqlite3Step+0xda
nss3!sqlite3_step+0x7d
nss3!sqlite3_exec+0xc9
xul!mozilla::storage::Connection::executeSql+0x3b
xul!mozilla::storage::Connection::ExecuteSimpleSQL+0x49
xul!mozilla::storage::Connection::BeginTransactionAs+0xb5
xul!mozStorageTransactionBase<mozilla::storage::Connection,nsRefPtr<mozilla::storage::Connection> >::mozStorageTransactionBase<mozilla::storage::Connection,nsRefPtr<mozilla::storage::Connection> >+0x37
xul!mozilla::storage::AsyncExecuteStatements::Run+0x66
xul!nsThread::ProcessNextEvent+0x2af
xul!NS_ProcessNextEvent+0x53
xul!mozilla::ipc::MessagePumpForNonMainThreads::Run+0xd5
xul!MessageLoop::RunHandler+0xa6
xul!MessageLoop::Run+0x3b
xul!nsThread::ThreadFunc+0xaf
nss3!_PR_NativeRunThread+0xcf
nss3!pr_root+0xf
MSVCR100!_endthreadex+0x3f
MSVCR100!_endthreadex+0xce
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x70
ntdll!_RtlUserThreadStart+0x1b

Comment 1

[D. Richard Hipp]

Is that database ever used by more than a single process.  (Use by multiple threads using separate connections does not count - I mean really used by multiple processes with their own address space.)  If not (and I think the answer is "no") then FF could set "PRAGMA locking_mode=EXCLUSIVE" immediately after opening the database and before doing anything else.  If that is done, then SQLite will use heap memory for the WAL-index, instead of mmapped shared memory, and this problem will never come up.  See http://www.sqlite.org/wal.html#noshm for additional information.