如何读取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是内存中的线路调用的指针。