如何读取Objective-C栈跟踪
我有以下堆栈跟踪：
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26 1 MyApp 0x000836bd TFSignalHandler + 28 2 libsystem_c.dylib 0x33eac727 _sigtramp + 34 3 ??? 0x00000002 0x0 + 2 4 MyApp 0x000803f1 msgpack_unpack_next + 112 5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74 6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26 7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146 ... 我想知道如何读取它：
- 我假设自己从底层走，例如第7行称为第6行，称为第5行，等等。
- 第4行的“+ 112”是什么意思？ 那是崩溃的代码文件中的行号？
- 什么'???' 在线3是什么意思？
非常感谢
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
碰撞产生于+[TFCrashHandler backtrace] + 26; 从任何指令落在该符号位置+ 26字节。
如果这真的是你的堆栈跟踪的底部，并在那里崩溃，那么TCrashHandler模糊了真正的崩溃。 真正的崩溃看起来是上面的几帧。
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler是所谓的+回溯。
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww …一个信号蹦床。 应用程序收到一个信号，蹦床被设置为调用TFSignalHandler（）。
在某些情况下，可能会在随机线程上调用信号处理程序。 即有一个很小的机会，这个特定的崩溃与parsing器没有任何关系，一切都与崩溃在别的地方。 然而，在不了解parsing器的情况下，我会怀疑它是否被恶意input（这肯定会导致这样的崩溃）。
3 ??? 0x00000002 0x0 + 2
堆栈是不可解的。 忽视。 无意义的。 最好的情况; 编译器优化后果。 最坏的情况下; 有人在堆栈上徘徊，回溯机制无法弄清楚发生了什么事（极不可能 – 通常，堆栈的脚趾飞溅到防止完全回溯的地步）。
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh …诡计。 有人正在使用C来parsing东西。 它坠毁。 无论从入口点到函数112字节的指令都是繁荣的 。 但是，并不是真的，因为它叫做信号处理程序，并由它来处理。 这仍然是一个繁荣，但信号处理程序已经有效地摧毁了额外的法医证据。
“trickzy”评论引用一个优化的编译器对一个大堆o'C可以最终崩溃的框架，以便崩溃可能发生在一个函数低于这一点。
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
MessagePackParser在事情发生严重错误时parsing。
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26 7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
啊…是的….有人完成从HTTP抓取一些数据，这是畸形的，导致崩溃。
底线; parsing器得到了假input并且崩溃了。 有一个信号处理程序试图通过创build回溯来帮助，但是 – 显然 – 没有真正透露更多的信息。 一个长远的select是，信号是在别的地方产生的，这个线程是随机select来处理它 – 如果你能一致地重新创build这个崩溃，那么随机线程信号的情况是不太可能的。
除非你有捕获的input数据，或者可以猜测msgpack_unpack_next（）如何崩溃，如果没有提供更多的信息，那么你是不幸的。
'???' 是无法识别的东西，可能是没有符号编译的代码，但也可能是别的东西。
这些是实现文件中的行号。 hex是内存中的线路调用的指针。
