How interpret stack traces when it stops on main

问题

Often I get stack traces such as this:

0 StackAsk 0x0007fc0d +[TFCrashHandler backtrace] + 429
1 StackAsk 0x0007fe4b TFHandleExceptions + 35
2 CoreFoundation 0x33d56987 __handleUncaughtException + 74
3 libobjc.A.dylib 0x3583d2d1 _objc_terminate + 128
4 libc++abi.dylib 0x34a763c5 _ZL19safe_handler_callerPFvvE + 76
5 libc++abi.dylib 0x34a76451 _ZdlPv + 0
6 libc++abi.dylib 0x34a77825 __cxa_current_exception_type + 0
7 libobjc.A.dylib 0x3583d235 objc_exception_rethrow + 12
8 CoreFoundation 0x33cac53d CFRunLoopRunSpecific + 404
9 CoreFoundation 0x33cac39d CFRunLoopRunInMode + 104
10 GraphicsServices 0x34f93439 GSEventRunModal + 136
11 UIKit 0x317a39f1 UIApplicationMain + 1080
12 StackAsk 0x0002c1c1 main (main.m:16)
13 StackAsk 0x0002c150 start + 40

(This log is from a tester, using TestFlightApp.com)

When this happens when I'm testing, the debugger stop on the main function.

The exception reason given was:

*** -[__NSArrayM objectAtIndex:]: index 17 beyond bounds [0 .. 16]

I can't replicate the crash myself, using a Release or Debug build configuration makes no difference. What can I do to get where the exception actually happened?

回答1:

Ask the tester to check for the crash report iOS generated, which would have the last exception backtrace which you can symbolicate and then see where it happens.

There are other crash report frameworks and services which do that, HockeyApp and QuincyKit (Note: I am involved in both). These are using PLCrashReporter which can also track the last exception backtrace and is safe to be used in the App Store too.

来源：https://stackoverflow.com/questions/8703404/how-interpret-stack-traces-when-it-stops-on-main

标签

objective-c

exception