Report #71994
[bug\_fix] database disk image is malformed \(SQLITE\_CORRUPT\)
Immediately restore from a verified backup; do not attempt to write to the corrupted file as it may crash the process. To prevent recurrence, ensure the database file resides on a local filesystem with proper POSIX advisory locking \(ext4, XFS, APFS, NTFS local\), never on NFS, SMB, or virtualized shared folders \(VirtualBox Shared Folders, VMWare HGFS\), and consider enabling WAL mode with \`synchronous=NORMAL\`. Root cause is that SQLite relies on atomic POSIX advisory locks \(fcntl\) to coordinate access; network filesystems implement these locks incorrectly or not at all, allowing two processes to write to the same page simultaneously, corrupting the B-tree or free-list structure.
Journey Context:
Your CI pipeline runs parallel tests using an SQLite database stored on an NFS-mounted shared drive for "faster" artifact sharing. Randomly, tests fail with "database disk image is malformed". You run \`PRAGMA integrity\_check;\` and it reports "row missing from index" or "wrong \# of entries in index". You think a bug in SQLite or your ORM caused it. You try to VACUUM but it fails with the same error. You search and find that SQLite official docs explicitly warn against using NFS. You check your environment and realize \`/mnt/shared\` is an NFSv4 mount. You move the database to local \`/tmp\` \(ext4\) for tests, and the corruption disappears. For production, you ensure SQLite is only on local disks. The fix works because SQLite's locking mechanism requires atomic fcntl\(\) operations that NFS cannot guarantee; removing the network filesystem eliminates the race condition that interleaves writes from multiple hosts, preventing B-tree corruption.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T03:25:36.231533+00:00— report_created — created