On 21 Feb 2018, at 2:35pm, Deon Brewis <de...@outlook.com> wrote: > 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
I'm puzzled by this. iOS gives applications quite a long time to terminate before calling "kill" on them. Had "applicationWillTerminate" been called ? Was it definitely your main thread (via thread 4) which was delaying the termination, and not another thread ? You should find the offending thread identified further up in that same report, just before it starts listing the call-stacks of each thread. If the offending call really was "sqlite3LeaveMutexAndCloseZombie" then you may have some sort of mismanagement in your code. Or it might be just a once-in-a-blue-moon problem which will never occur again. The rest I lave up to the devs. SQLite should not be corrupting a database just because it was unexpectedly terminated, no matter what it was doing when terminated. It was written to avoid that and no amount of testing has shown such a bug. > SQLITE3 version is 3.20.1. Database size is around 5 GB. You have a 5 GB database on a device which may have a 16 GB capacity ? I assume you know what you're doing. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
