Interesting case of database corruption on iOS here.
Our main thread was waiting for a worker thread to exit. The worker thread was
doing a sqlite3Close, which in turn did a checkpoint.
The application got watchdog terminated by iOS because the main thread was
taking too long (waiting for the sqlite3close on the worker thread). The
resultant force close seems to have aborted SQLITE in such a way that it caused
the database to be corrupted.
Worker thread stack:
Thread 4:
ftruncate: external code (libsystem_kernel.dylib)
unixTruncate: sqlite3.c @ 34036
sqlite3WalCheckpoint: sqlite3.c @ 56846
sqlite3WalClose: sqlite3.c @ 56955
sqlite3PagerClose: sqlite3.c @ 51556
sqlite3BtreeClose: sqlite3.c @ 62169
sqlite3LeaveMutexAndCloseZombie: sqlite3.c @ 142752
sqlite3Close: sqlite3.c @ 0
SQLITE3 version is 3.20.1. Database size is around 5 GB.
Couple of questions:
a) Is it expected that an app crash / force terminate in the middle of a
SQLITE3 checkpoint like this can cause corruption?
b) Is there a way I can do a close without triggering a checkpoint? (In order
to speed up close, so that it doesn't trigger a watchdog).
- Deon
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
