我有以下堆栈跟踪：
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
...
我想知道如何阅读它：
非常感谢
答案 0 :(得分：60)
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
从+[TFCrashHandler backtrace] + 26生成崩溃;从任何指令落在该符号位置+ 26个字节。
如果这确实是堆栈跟踪的底部并且在那里崩溃，那么TCrashHandler会掩盖真正的崩溃。真正的崩溃看起来是上面几帧。
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler叫做+ backtrace。
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
在某些情况下，可能会在随机线程上调用信号处理程序。即这个特定的崩溃与解析器无关，并且与其他地方的崩溃无关。但是，在不了解更多关于解析器的情况下，我会质疑它是否能够抵御恶意输入（这肯定会导致像这样的崩溃）。
3 ??? 0x00000002 0x0 + 2
Stack无法解码。忽视。无意义的。最好的情况;编译器优化的后果。最糟糕的情况;有人在堆栈上进行操作，而回溯机制无法弄清楚发生了什么（非常不可能 - 通常情况下，堆栈大便会溅到防止完全回溯的程度）。
4 MyApp 0x000803f1 msgpack_unpack_next + 112
哦......狡猾。有人用C来解析东西。它崩溃了。无论从入口点到函数的112个字节是什么指令都 boom 。但是，不是真的，因为它调用了信号处理程序并由此处理;这仍然是一个繁荣，但信号处理程序已经有效地破坏了额外的法医证据。
“trickzy”注释引用了针对大堆的优化编译器可以最终将帧折叠到崩溃可能发生在远低于此值的函数中。
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
当事情发生可怕的错误时，MessagePackParser正在解析。
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
啊......是的....有人从HTTP中抓取了一些数据并且格式不正确导致了崩溃。
底线;解析器得到虚假输入并崩溃。有一个信号处理程序，试图通过创建一个回溯来帮助，但 - 显然 - 并没有真正揭示任何更多的信息。远程替代方案是信号是在其他地方生成的，并且随机选择此线程来处理它 - 如果您可以一致地重新创建此崩溃，则不太可能出现随机线程信号情况。
除非您捕获输入数据或者可以猜测msgpack_unpack_next（）可能会如何崩溃，否则在没有提供更多信息的情况下运气不佳。
答案 1 :(得分：3)
'???'是一些无法识别的东西，可能是没有符号编译的代码，但也可能是其他东西。
答案 2 :(得分：-2)
这些是实现文件中的行号。十六进制是内存中指向行调用的指针。