如果抛出未处理的NSException，则堆栈跟踪的部分如下所示：
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
...
但是如果抛出std :: exception，我只得到这个：
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
如何从此崩溃日志中获取确切的崩溃信息？
更新 -
我给了HockeyApp一个镜头，但它与iTunes崩溃日志有相同的限制 - 它没有告诉我未处理的C ++异常的堆栈。
答案 0 :(得分：22)
你所看到的是AppKit和UIKit的一个不幸的怪癖。 iOS和OS X都在CFRunLoop中有一个异常处理程序，用于捕获所有未捕获的异常。在OS X上，处理程序通过对话框向用户显示异常，但在iOS上，处理程序只是重新抛出异常。
由NSException实现的Objective-C异常，在实际“throw”发生之前将它们的回溯保存在异常对象中，作为[NSException init]（或类似的初始化方法）的一部分。不幸的是，C ++异常不会这样做。通常，C ++异常具有回溯，因为运行时库检测到没有catch并立即调用std::terminate，而abort()又调用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
，使整个调用堆保持不变，如下所示：
catch但是，当运行循环异常处理程序捕获异常时，执行将在std::terminate块内正常恢复。因此原始的回溯就会丢失。重新抛出随后调用NSException，但此时，调用堆栈反映了运行循环异常处理程序。
要在这种情况下从C ++异常中获取回溯，您必须抛出一个模仿std::exception的异常对象，并将调用堆栈作为其构造函数的一部分进行读取，并确保代码中抛出所有异常照着做。 CFRunLoop不会执行此操作，并且您使用的任何第三方代码都不可能。
向Apple提出错误，要求他们删除{{1}}异常处理程序，或者至少提供一个用于关闭它的API。现在这样做没有API，甚至没有SPI。
答案 1 :(得分：3)
我很幸运能够提高mpipe3的答案。
在我的main方法中，我使用try-catch来获取C ++异常，然后在dispatch_sync上调用dispatch_get_global_queue。现在，带有行号的完整堆栈跟踪将显示在Crashlytics（崩溃管理器）上。
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;
}
}
这可以通过使用GCD抛出异常来避免CFRunLoop异常处理程序。
答案 2 :(得分：0)
继Gwynne Raskind回答之后，您可以通过使用GCD同步调度C ++代码块来避免CFRunLoop异常处理程序：
namespace
{
void MyThrowingCode()
{
throw std::runtime_error("My Exception");
}
}
- (void)objcHandlerCalledFromARunLoop
{
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
MyThrowingCode();
});
}
您可能需要创建自己的队列，而不是使用单个共享队列。
崩溃日志如下所示：
0 libsystem_kernel.dylib 0x3aa39350 __pthread_kill + 8
1 libsystem_c.dylib 0x3a9affb2 pthread_kill + 54
2 libsystem_c.dylib 0x3a9ec366 abort + 90
3 libc++abi.dylib 0x39f94dda abort_message + 70
4 libc++abi.dylib 0x39f92094 default_terminate() + 20
5 libobjc.A.dylib 0x3a545a70 _objc_terminate() + 168
6 libc++abi.dylib 0x39f92118 safe_handler_caller(void (*)()) + 76
7 libc++abi.dylib 0x39f921b0 std::terminate() + 16
8 libc++abi.dylib 0x39f9359a __cxa_throw + 118
9 Test 0x000fddfc MyThrowingCode() (MainViewController.mm:177)
10 Test 0x000fe38c __35-[MainViewController toolsClick:]_block_invoke (MainViewController.mm:184)
11 libdispatch.dylib 0x3a95f5d8 _dispatch_client_callout + 20
12 libdispatch.dylib 0x3a962776 _dispatch_sync_f_invoke + 22
13 Test 0x000fde90 -[MainViewController toolsClick:] (MainViewController.mm:183)
14 UIKit 0x34744082 -[UIApplication sendAction:to:from:forEvent:] + 66
15 UIKit 0x3474410c -[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 116
16 UIKit 0x34744082 -[UIApplication sendAction:to:from:forEvent:] + 66
17 UIKit 0x34744036 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
18 UIKit 0x34744010 -[UIControl sendAction:to:forEvent:] + 40
19 UIKit 0x347438c6 -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
20 UIKit 0x34743db4 -[UIControl touchesEnded:withEvent:] + 484
21 UIKit 0x3466c5f4 -[UIWindow _sendTouchesForEvent:] + 520
22 UIKit 0x346598dc -[UIApplication sendEvent:] + 376
23 UIKit 0x346591ea _UIApplicationHandleEvent + 6194
24 GraphicsServices 0x363715f4 _PurpleEventCallback + 588
25 GraphicsServices 0x36371222 PurpleEventCallback + 30
26 CoreFoundation 0x3281f3e4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
27 CoreFoundation 0x3281f386 __CFRunLoopDoSource1 + 134
28 CoreFoundation 0x3281e20a __CFRunLoopRun + 1378
29 CoreFoundation 0x32791238 CFRunLoopRunSpecific + 352
30 CoreFoundation 0x327910c4 CFRunLoopRunInMode + 100
31 GraphicsServices 0x36370336 GSEventRunModal + 70
32 UIKit 0x346ad2b4 UIApplicationMain + 1116
33 Test 0x00120462 main (main.mm:55)
34 libdyld.dylib 0x3a972b1c start + 0
答案 3 :(得分：-2)
看起来异常发生在UIApplicationMain（）内部...您可以尝试将main.m文件转换为main.mm文件，并执行此操作：
int main(...)
{
try
{
return UIApplicationMain(...);
}
catch( exception e )
{
cerr < e.what() ;
}
}
我实际上并没有尝试，但是......