iOS: How to get stack trace of an unhandled std::exception?

Question

If an unhandled NSException is thrown, the stack trace has a section like this:

Last Exception Backtrace:
0   CoreFoundation                  0x32bd688f __exceptionPreprocess + 163
1   libobjc.A.dylib                 0x34b7b259 objc_exception_throw + 33
2   CoreFoundation                  0x32bd65c5 -[NSException init] + 1
3   Foundation                      0x37296bd7 -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 263
...

But if std::exception is thrown, i get only this:

Thread 0 Crashed:
0   libsystem_kernel.dylib          0x34f2632c __pthread_kill + 8
1   libsystem_c.dylib               0x31e4c208 pthread_kill + 48
2   libsystem_c.dylib               0x31e45298 abort + 88
3   libc++abi.dylib                 0x33bcaf64 abort_message + 40
4   libc++abi.dylib                 0x33bc8346 default_terminate() + 18
5   libobjc.A.dylib                 0x349f4368 _objc_terminate + 164
6   libc++abi.dylib                 0x33bc83be safe_handler_caller(void (*)()) + 70
7   libc++abi.dylib                 0x33bc844a std::terminate() + 14
8   libc++abi.dylib                 0x33bc981e __cxa_rethrow + 82
9   libobjc.A.dylib                 0x349f42a2 objc_exception_rethrow + 6
10  CoreFoundation                  0x329a5506 CFRunLoopRunSpecific + 398
11  CoreFoundation                  0x329a5366 CFRunLoopRunInMode + 98
12  GraphicsServices                0x32af2432 GSEventRunModal + 130
13  UIKit                           0x34f84cce UIApplicationMain + 1074
14  APP_NAME                            0x00086b10 main (main.m:68)
15  APP_NAME                        0x00071b98 start + 32

How do I get the exact crash info from this crash log?

Update --

I've given HockeyApp a shot, but it has the same limitation as iTunes crash logs - it doesn't tell me the stack for an unhandled C++ exception.

Answer 1

What you're seeing is an unfortunate quirk of AppKit and UIKit. Both iOS and OS X have an exception handler in CFRunLoop that traps all uncaught exceptions. On OS X, the handler displays the exception to the user with a dialog box, but on iOS, the handler simply rethrows the exception.

Objective-C exceptions, as implemented by NSException, save their backtraces within the exception object right before the actual "throw" happens, as part of [NSException init] (or a similar initializer method). Unfortunately, C++ exceptions don't do the same. Normally, a C++ exception has a backtrace because the runtime library detects that there's no catch and immediately calls std::terminate, which in turn calls abort(), leaving the entire call stack intact, like so:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff93ef8d46 __kill + 10
1   libsystem_c.dylib               0x00007fff89968df0 abort + 177
2   libc++abi.dylib                 0x00007fff8beb5a17 abort_message + 257
3   libc++abi.dylib                 0x00007fff8beb33c6 default_terminate() + 28
4   libobjc.A.dylib                 0x00007fff8a196887 _objc_terminate() + 111
5   libc++abi.dylib                 0x00007fff8beb33f5 safe_handler_caller(void (*)()) + 8
6   libc++abi.dylib                 0x00007fff8beb3450 std::terminate() + 16
7   libc++abi.dylib                 0x00007fff8beb45b7 __cxa_throw + 111
8   test                            0x0000000102999f3b main + 75
9   libdyld.dylib                   0x00007fff8e4ab7e1 start + 1

However, when the run loop exception handler traps the exception, execution resumes normally within the catch block. The original backtrace is therefore lost. The rethrow subsequently calls std::terminate, but at this point, the call stack reflects the run loop exception handler.

To get a backtrace from a C++ exception in this circumstance, you have to throw an exception object which mimics NSException and reads the call stack as part of its constructor, and make sure that all exceptions thrown in your code do the same. std::exception doesn't do this, and it's not at all likely that any third-party code you're using will either.

File a bug with Apple asking them to remove the CFRunLoop exception handler, or at least provide an API for shutting it off. There is no API, not even an SPI, for doing this right now.

Answer 2

I've had luck with improving mpipe3's answer.

In my main method, I use a try-catch to get the C++ exception and then call a dispatch_sync on dispatch_get_global_queue. Now the full stack trace with line numbers will show on Crashlytics (crash manager).

int main(int argc, char *argv[]) {

@autoreleasepool {
    @try{
        return UIApplicationMain(argc, argv, nil, @"AppControllerClassName");
    } @catch (NSException *exception) {/* Catch any uncaught exceptions and print out a friendly call stack. Instead of an ugly memory addresses. */
        NSString * message = [NSString stringWithFormat:@"Uncaught exception %@ : %@\n %@", exception.name, exception.reason, [exception callStackSymbols]];
        [LogManager e:@"main.m" Message:message Exception: exception];
        @throw;
    } @catch (...){
        //Attempt to get the correct stacktrace for C++ exceptions.
        dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            @throw;
        });
    }
    return 0;
}
}

This works as it avoids the CFRunLoop exception handler by using GCD to throw the exception.