How to analyse app crashed in main thread with uncaught exception rethrown by CFRunLoop with no proper backtrace

My app crashes in the main thread, the crash happens randomly no definite pattern and happens only on iPad OS, the crash never occurred on iPhone. Can someone helpmeet how to proceed with analysing this crash log. It looks like a uncaught exception was thrown but it was trapped by CFRunLoop exception handler and actual backtrace is lost.

Can someone help me to analyse this log or how to get actual backtrace ?

Consider this:

Thread 0 Crashed:
0   libsystem_kernel.dylib  … __pthread_kill + 8
1   libsystem_pthread.dylib … pthread_kill + 208
2   libsystem_c.dylib       … raise + 28
3   NcpClient               … ncp::ncppal_terminate+ 820756 () + 172
4   libc++abi.dylib         … std::__terminate(void (*)()) + 12
5   libc++abi.dylib         … std::terminate() + 52
6   libdispatch.dylib       … _dispatch_client_callout + 36
7   libdispatch.dylib       … _dispatch_main_queue_drain + 928
8   libdispatch.dylib       … _dispatch_main_queue_callback_4CF$VARIANT$mp + 36
9   CoreFoundation          … __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10  CoreFoundation          … __CFRunLoopRun + 2080

Something has thrown an unhandled exception which is terminating your process. That then invokes your termination handler (frame 3) which is terminating it harder (-:

As to what the original thing is, it’s hard to say. There are two potential complications here:

  • The thrown exception was a C++ exception. This is a known limitation of the crash reporting system. See this thread for more.

  • The exception was thrown by Objective-C but something is preventing the Last Exception Backtrace from being generated for it.

Given that you’re using C++, I suspect the former. A good way to test that theory is to add some UI to deliberately throw each exception type from the same context, and then see what the resulting crash reports look like. I suspect that you’ll see a Last Exception Backtrace for the Objective-C exception and not for the C++ exception. If so, that confirms my first theory.

And what is that context? Well, frames 10 through 7 above indicate that this is a block that’s been scheduled on the main queue. So, you could write code like this:

- (IBAction)testAction:(id)sender {
    dispatch_async(dispatch_get_main_queue(), ^{
        @throw [NSException exceptionWithName:@"…" reason:@"…" userInfo:nil];
    });
}

and the equivalent in C++.


Of course, once you confirm that this is a C++ exception the next step is to actually track it down, and that’s always a challenge.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

How to analyse app crashed in main thread with uncaught exception rethrown by CFRunLoop with no proper backtrace
 
 
Q