Yes, definitely the main thread - we close down the database during
applicationWillTerminate. It gives us 5 seconds to exit before it triggers the
watchdog.
Termination Description: SPRINGBOARD, process-exit watchdog transgression: xxx
exhausted real (wall clock) time allowance of 5.00 seconds | |
ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent:
process-exit | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( |
"Elapsed total CPU time (seconds): 3.740 (user 3.740, system 0.000), 25% CPU",
| "Elapsed application CPU time (seconds): 0.049, 0% CPU" | )
Triggered by Thread: 0
Thread 0 crashed:
__semwait_signal: external code (libsystem_kernel.dylib)
nanosleep: external code (libsystem_c.dylib)
+[NSThread sleepForTimeInterval:]: external code (Foundation)
Database::signalCloseAndWait()
App::~App()
-[AppDelegate applicationWillTerminate:]: appdelegate.mm @ 377
-[UIApplication _terminateWithStatus:]: external code (UIKit)
"If the offending call really was "sqlite3LeaveMutexAndCloseZombie" then you
may have some sort of mismanagement in your code"
What do you mean by that? Is it abnormal for sqlite3close to call
sqlite3LeaveMutexAndCloseZombie?
- Deon
-----Original Message-----
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Simon Slavin
Sent: Wednesday, February 21, 2018 7:23 AM
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] iOS Watchdog and database corruption
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
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailinglists.sqlite.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsqlite-users&data=02%7C01%7C%7C84050f4c5810477347f708d5793effe3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548233837936119&sdata=ALIGynOvAu4HWcRE3wlBELXyEjC39PDXTYJDSNnJiqc%3D&reserved=0
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
