iOS 崩溃日志 Backtrace的符号化

iOS 崩溃日志 Backtrace的符号化

iOS的崩溃日志配合dsym文件可以找到崩溃时的backtrace,这是解决崩溃的最重要的信息.

如果是在同一台mac上打包, 导入crash log时候会自动将backtrace符号化,可以看到方法名, 文件名和行号

但是,有时候发版的包不是在你的mac上打包的,xcode找不到对应的符号表, backtrace没能符号化如下所示:

Last Exception Backtrace:
0 CoreFoundation 0x2cb535f2 __exceptionPreprocess + 122
1 libobjc.A.dylib 0x3a3c5c72 objc_exception_throw + 34
2 CoreFoundation 0x2ca67152 -[__NSArrayM objectAtIndex:] + 226
3 myapp 0x004fe736 0x9b000 + 4601654
4 myapp 0x00507ed4 0x9b000 + 4640468
5 myapp 0x004fd112 0x9b000 + 4595986
6 myapp 0x003275c6 0x9b000 + 2672070

这里第二行可以看到是一个数组objectAtIndex抛出异常,但是3-6行的是来自应用自己的代码myapp, 这些信息才是最重要的.

其实,只要有原app文件,是可以将这些信息找到.

方法:

将对应版本的myapp.app文件和crash文件放在同一个文件夹下, 注意,一定要是该应用正确版本的app, 因为每次打包, 符号表的映射关系都有可能不同,如果不对应的话是没法符号化的.

然后运行

atos -arch armv7 -o myapp.app/myapp -l 0x9b000 0x004fe736

这个方法 -arch后面是指硬件架构:
iphone 1,2,3 是armv6
iphone4,4s 是 armv7
iphone5,5c是armv7s
iphone 5s, 6, 6+, 6s, 6s+ 是arm64

根据崩溃发生的设备来选择上述架构, myapp.app就是你的app的文件名, 选项l后面的两个16进制数是关键:
第一个数字,取backtrace的要解析的行的第4列, 第二个数字取第3列, 就会得到对应的方法名,文件名,行号.
这样,可以将上述3-6行中一行一行的解析出来,就能看到发生崩溃的地方,再进行分析就简单了.