如何读取objective-c堆栈跟踪 [英] How to read objective-c stack traces

问题描述

我有以下堆栈跟踪：

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个字节。

Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.

如果这真的是堆栈跟踪的底部并且在那里崩溃，那么 TCrashHandler 掩盖了真正的崩溃。真正的崩溃看起来是上面几帧。

If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.

1 MyApp 0x000836bd TFSignalHandler + 28

TFSignalHandler叫做+ backtrace。

TFSignalHandler was what called +backtrace.

2 libsystem_c.dylib 0x33eac727 _sigtramp + 34

Ewww ...信号蹦床。应用程序收到一个信号，蹦床设置为调用TFSignalHandler（）。

Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().

在某些情况下，可能会在随机线程上调用信号处理程序。即这个特定的崩溃与解析器无关，并且与其他地方的崩溃无关。但是，如果不了解有关解析器的更多信息，我会质疑它是否能够抵御恶意输入（这肯定会导致这样的崩溃）。

There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).

3 ??? 0x00000002 0x0 + 2

Stack无法解码。忽视。无意义的。最好的情况;编译器优化的后果。最坏的情况下;有人在堆栈上进行了操作并且回溯机制无法弄清楚发生了什么（非常不可能 - 通常情况下，堆栈大便会飞溅到防止完全回溯的程度）。

Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).

4 MyApp 0x000803f1 msgpack_unpack_next + 112

Ooooh ..欺骗。有人用C来解析东西。它崩溃了。无论从入口点到函数的112字节是什么指令都 boom 。但是，不是真的，因为它调用信号处理程序并由此处理;这仍然是一个繁荣，但信号处理程序已经有效地破坏了额外的取证证据。

Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.

trickzy注释引用了针对a的优化编译器大堆o C可以最终折叠框架到崩溃可能发生在远低于这一点的函数中。

The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.

5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74

当事情发生严重错误时，MessagePackParser正在解析。

MessagePackParser was parsing when things went horribly wrong.

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

啊......是的......有人完成了从HTTP中获取了一些数据并且格式错误导致崩溃。

Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.

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

Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.

除非您捕获输入数据或者可以猜测msgpack_unpack_next（）可能会如何崩溃，否则在没有提供更多信息的情况下运气不佳。

Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.

这篇关于如何读取objective-c堆栈跟踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！