如何读取objective-c堆栈跟踪

Chr*_*ris 37 iphone objective-c stack-trace

我有以下堆栈跟踪:

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
...
Run Code Online (Sandbox Code Playgroud)

我想知道如何阅读它:

  • 我假设我从下往上,例如第7行称为第6行,称为第5行,等等.
  • 第4行的'+ 112'是什么意思?这是代码文件中的行号,它崩溃了吗?
  • 什么是'???' 3号线是什么意思?

非常感谢

bbu*_*bum 61

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Run Code Online (Sandbox Code Playgroud)

崩溃来自+[TFCrashHandler backtrace]+ 26; 从任何指令落在该符号位置+ 26个字节.

如果那真的是你的堆栈跟踪的底部并且它在那里崩溃,那么它TCrashHandler就会模糊真正的崩溃.真正的崩溃看起来是上面几帧.

1 MyApp 0x000836bd TFSignalHandler + 28
Run Code Online (Sandbox Code Playgroud)

TFSignalHandler叫做+ backtrace.

2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Run Code Online (Sandbox Code Playgroud)

Ewww ...一个信号蹦床.应用程序收到一个信号,蹦床设置为调用TFSignalHandler().

在某些情况下,可能会在随机线程上调用信号处理程序.也就是说,这个特定的崩溃与解析器无关,并且与其他地方的崩溃无关.但是,在不了解更多关于解析器的情况下,我会质疑它是否能够抵御恶意输入(这肯定会导致像这样的崩溃).

3 ??? 0x00000002 0x0 + 2
Run Code Online (Sandbox Code Playgroud)

堆栈是不可解码的.忽视.无意义的.最好的情况; 编译器优化的后果.最糟糕的情况; 有人在堆栈上进行了操作并且回溯机制无法弄清楚发生了什么(非常不可能 - 通常情况下,堆栈大便会出现阻止完全回溯的程度).

4 MyApp 0x000803f1 msgpack_unpack_next + 112
Run Code Online (Sandbox Code Playgroud)

哦啊......很诡异.有人用C来解析东西.它崩溃了.无论从入口点到函数的112个字节是什么指令都是繁荣的.但是,不是真的,因为它调用了信号处理程序并由此处理; 这仍然是繁荣,但信号处理者已经有效地破坏了额外的法医证据.

"trickzy"注释引用了针对大堆的优化编译器可以最终将帧折叠到崩溃可能发生在远低于此值的函数中的点.

5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
Run Code Online (Sandbox Code Playgroud)

当事情发生可怕的错误时,MessagePackParser正在解析.

6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
Run Code Online (Sandbox Code Playgroud)

啊......是的......有人从HTTP中抓取了一些数据并且格式不正确导致了崩溃.

底线; 解析器得到虚假输入并崩溃.有一个信号处理程序,试图通过创建一个回溯来帮助,但 - 显然 - 并没有真正揭示任何更多的信息.远程替代方案是信号是在其他地方生成的,并且随机选择此线程来处理它 - 如果您可以始终如一地重新创建此崩溃,则不太可能出现随机线程信号情况.

除非您捕获输入数据或者可以猜测msgpack_unpack_next()可能会崩溃,否则在没有提供更多信息的情况下运气不好.