Here is the crash log
Thanks.
When you post a crash report it’s best to post the whole crash report. In many cases the only way to get useful results from a crash report is to look at the thing as a whole. Fortunately that’s not the case here. If you look at the backtrace for thread 0 there’s some useful clues. But first, some background…
There are two standard terminate paths your app can follow:
Terminate while suspended (A) — When the user moves your app to the background the system typically will typically suspend it shortly thereafter. Once the app is suspended the system can remove your app from memory without resuming it.
Terminate while active (B) — In some situations the system may need to terminate your app while it’s active. In this case code within your app runs to trigger the termination. You can hear about this by implementing the
-applicationWillTerminate:
app delegate method.
Case A has been by far the most common since multitasking was introduced in iOS 4. However, case B does still crop up.
In seems that your app is crashing in case B. Specifically, frames 9 and 8 clearly show that UIKit is terminating your app by calling
exit
. Frame 7 indicates that the system is running an
atexit
handler. Frame 6 suggests that this
atexit
handler is something related to strings. Frame 5 indicates that the
atexit
handler has called
free
. And frameworks 4 through 0 are that call failing for some reason (usually this is either a bad parameter or a corrupt heap).
To investigate this you test case B. You can do this by removing your app from the multitasking UI when it’s at the front. Implement
-applicationWillTerminate:
and set a breakpoint there to confirm that you’re actually hitting case B. From there you can try to track down who installed this
atexit
handler and why it’s crashing.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"