日常开发中,我们难免遇到一些 crash。大部分情况下,Xcode 可以帮助我们找到问题所在,但也有些情况,Xcode 给我们反馈的是一些看不懂的地址,大大增加了我们分析问题的难度。
下面,就来介绍几种能让看不懂的地址,变得看的懂的方式。
dSYM 是保存十六进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中。每次编译项目的时候都会生成一个新的 dSYM 文件,我们应该保存每个正式发布版本的 dSYM 文件,以备我们更好的调试问题。一般是在我们 Archives 时保存对应的版本文件的,里面也有对应的.dSYM和.app文件。路径为:
~/Library/Developer/Xcode/Archives
.dSYM文件默认在 debug 模式下是不生成的,我们去 Build Settings -> Debug Information Format 下,将DWARF修改为DWARF with dSYM File,再重新编译下就能生成.dSYM文件了,直接去项目工程的Products目录下找就行。
引用 《程序员的自我修养》中的解释:
在链接中,我们将函数和变量统称为符号(Symbol),函数名或变量名就是符号名(Symbol Name)。我们可以将符号看作是链接中的粘合剂,整个链接过程正是基于符号才能够正确完成。
所以,所谓的 symbols 就是函数名或变量名。
symbolicatecrash是 Xcode 自带的 crash 日志分析工具,我们需要先找到它:
find /Applications/Xcode.app -name symbolicatecrash -type f
执行完后会返回几个路径,我的是:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash
我们到这个路径下把symbolicatecrash拷贝出来,放到一个文件夹下。
我们可以随便写段强制 crash 的代码:
- (void)touchesBegan:(NSSet*)touches withEvent:(UIEvent *)event {
NSArray *arr = @[];
arr[100];
}
接着用真机打个包。打好包之后,不要用 Xcode build,直接用打好的包运行我们能导致 crash 的代码,这样就生成好.crash日志文件了。
之后,我们去 Xcode -> Window -> Devices and Simulators 或者快捷键 Command + Shift + 2
找到对应时间点的 .crash 文件,右击 Export Log。
.app文件可以使用真机编译下,去 项目Products目录下获取,也可以去 Archives 目录下获取。
将.dSYM、.crash及symbolicatecrash放到同一个文件下,执行命令:
./symbolicatecrash .crash文件路径 .dSYM文件路径 > 名字.crash
将.app、.crash及symbolicatecrash放到同一个文件下,执行命令:
./symbolicatecrash .crash文件路径 .app/appName 路径 > 名字.crash
可能会报错误:
Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.
执行下命令就行:
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
然后再重新生成下新的.crash文件就行。
我们可以对比下没有符号化和符号化的文件,下面是我自己测试的例子,iPhone5 iOS 10.2, 可能会有所不同:
Last Exception Backtrace:
0 CoreFoundation 0x1df60df2 __exceptionPreprocess + 126
1 libobjc.A.dylib 0x1d1c3072 objc_exception_throw + 33
2 CoreFoundation 0x1dee62f2 -[__NSArray0 objectAtIndex:] + 105
3 DreamDemo 0x0008088e 0x7c000 + 18574
4 UIKit 0x2319eb44 forwardTouchMethod + 289
5 UIKit 0x2319ea10 -[UIResponder touchesBegan:withEvent:] + 29
6 UIKit 0x23041c58 -[UIWindow _sendTouchesForEvent:] + 1599
7 UIKit 0x2303ca62 -[UIWindow sendEvent:] + 2657
8 UIKit 0x2300d870 -[UIApplication sendEvent:] + 315
9 UIKit 0x237a8998 __dispatchPreprocessedEventFromEventQueue + 2615
10 UIKit 0x237a25de __handleEventQueue + 829
11 CoreFoundation 0x1df1c716 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 7
12 CoreFoundation 0x1df1c220 __CFRunLoopDoSources0 + 433
13 CoreFoundation 0x1df1a4f6 __CFRunLoopRun + 757
14 CoreFoundation 0x1de6952e CFRunLoopRunSpecific + 481
15 CoreFoundation 0x1de6933c CFRunLoopRunInMode + 99
16 GraphicsServices 0x1f640bf8 GSEventRunModal + 151
17 UIKit 0x230789a2 -[UIApplication _run] + 569
18 UIKit 0x230730cc UIApplicationMain + 145
19 DreamDemo 0x000834cc 0x7c000 + 29900
20 libdyld.dylib 0x1d633506 _dyld_process_info_notify_release + 23
问题也能看出来,但是因为第三行(DreamDemo)并没有符号化,导致我们并不确定具体调用位置。
再来看看符号化之后的:
Last Exception Backtrace:
0 CoreFoundation 0x1df60df2 __exceptionPreprocess + 126
1 libobjc.A.dylib 0x1d1c3072 objc_exception_throw + 33
2 CoreFoundation 0x1dee62f2 -[__NSArray0 objectAtIndex:] + 105
3 DreamDemo 0x0008088e -[ViewController touchesBegan:withEvent:] + 18574 (ViewController.m:84)
4 UIKit 0x2319eb44 forwardTouchMethod + 289
5 UIKit 0x2319ea10 -[UIResponder touchesBegan:withEvent:] + 29
6 UIKit 0x23041c58 -[UIWindow _sendTouchesForEvent:] + 1599
7 UIKit 0x2303ca62 -[UIWindow sendEvent:] + 2657
8 UIKit 0x2300d870 -[UIApplication sendEvent:] + 315
9 UIKit 0x237a8998 __dispatchPreprocessedEventFromEventQueue + 2615
10 UIKit 0x237a25de __handleEventQueue + 829
11 CoreFoundation 0x1df1c716 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 7
12 CoreFoundation 0x1df1c220 __CFRunLoopDoSources0 + 433
13 CoreFoundation 0x1df1a4f6 __CFRunLoopRun + 757
14 CoreFoundation 0x1de6952e CFRunLoopRunSpecific + 481
15 CoreFoundation 0x1de6933c CFRunLoopRunInMode + 99
16 GraphicsServices 0x1f640bf8 GSEventRunModal + 151
17 UIKit 0x230789a2 -[UIApplication _run] + 569
18 UIKit 0x230730cc UIApplicationMain + 145
19 DreamDemo 0x000834cc main + 29900 (main.m:15)
20 libdyld.dylib 0x1d633506 _dyld_process_info_notify_release + 23
可以发现,第三行被解析出来了,这样我们就能很清晰的知道具体的页面了。
symbolicatecrash 可以帮助我们很好的分析 crash 日志,但是有它的局限性 --- 不够灵活。我们需要symbolicatecrash、.crash及.dSYM三个文件才能解析。
相对于 symbolicatecrash,atos命令更加灵活,特别是你需要对不同渠道的 crash 文件,写一个自动化的分析脚本的时候,这个方法就极其有用。
但是这种方式也有个不方便的地方:一个线上的 App,用户使用的版本存在差异,而每个版本所对应的.dSYM都是不同的。必须确保.crash和.dSYM文件是匹配的,才能正确符号化,匹配的条件就是它们的 UUID 一致。 在这之前,先介绍下 UUID:
UUID 是由一组 32 位数的十六进制数字所构成。每一个可执行程序都有一个 build UUID 唯一标识。.crash日志包含发生 crash 的这个应用的 build UUID 以及 crash 发生时,应用加载的所有库文件的 build UUID。
执行命令:
grep --after-context=2 "Binary Images:" *crash
输出:
T.crash:Binary Images:
T.crash-0x7c000 - 0x87fff DreamDemo armv7 /var/containers/Bundle/Application/DEEBE571-D512-4E8F-B712-ED4D19CE64F9/DreamDemo.app/DreamDemo
T.crash-0xa9000 - 0xd4fff dyld armv7s /usr/lib/dyld
看到上面的输出d009f8671129397a8aab9cb2b8e506ff就是DreamDemo项目的 UUID。
执行命令:
dwarfdump --uuid DreamDemo.app.dSYM
输出:
UUID: D009F867-1129-397A-8AAB-9CB2B8E506FF (armv7) DreamDemo.app.dSYM/Contents/Resources/DWARF/DreamDemo
执行命令:
dwarfdump --uuid DreamDemo.app/DreamDemo
输出:
UUID: D009F867-1129-397A-8AAB-9CB2B8E506FF (armv7) DreamDemo.app/DreamDemo
可以发现这两个文件的 UUID 是相同的,也就是匹配的,只有满足这种条件,才能正确的解析!
我们现回顾下未解析前的堆栈:
2 CoreFoundation 0x1dee62f2 -[__NSArray0 objectAtIndex:] + 105
3 DreamDemo 0x0008088e 0x7c000 + 18574
4 UIKit 0x2319eb44 forwardTouchMethod + 289
5 UIKit 0x2319ea10 -[UIResponder touchesBegan:withEvent:] + 29
执行命令:
xcrun atos -o DreamDemo.app.dSYM/Contents/Resources/DWARF/DreamDemo -arch armv7 -l 0x7c000
接着输入0x0008088e地址,终端输出如下:
可以发现,正确的解析出来了!
除了搭配.dSYM文件,我们也可以使用.app文件来解析:
执行命令:
xcrun atos -o DreamDemo.app/DreamDemo -arch armv7 -l 0x7c000
同样输入0x0008088e地址,效果是一样的。
直接操作atos命令毕竟是有点不方便,GitHub 上有个工具,可以辅助我们解析 dSYMTools ,这是个 Mac 客户端,界面长这样:
使用起来也很方便,我们只需要把对应的dSYM文件拖进去,它会自动识别 UUID。我们对应的输入参数地址就行:
细心的人可以发现,我们上面的解析都是针对DreamDemo,这个自己的项目的。其实很多系统方法的堆栈之所以能解析出来,是因为已经有了系统库的符号化文件,存放目录如下:
/用户/用户名称xxx/资源库/Developer/Xcode/iOS DeviceSupport
这些库的版本都是和.crash文件中是对应的:
OS Version: iPhone OS 10.2 (14C5077b)
一旦我把这个10.2 (14C5077b)系统的符号化库删掉,.crash文件就会变成这样:
Last Exception Backtrace:
0 CoreFoundation 0x1df60df2 0x1de5f000 + 1056242
1 libobjc.A.dylib 0x1d1c3072 0x1d1bc000 + 28786
2 CoreFoundation 0x1dee62f2 0x1de5f000 + 553714
3 DreamDemo 0x000bc66e -[ViewController touchesBegan:withEvent:] + 18030 (ViewController.m:78)
4 UIKit 0x2319eb44 0x22ffe000 + 1706820
5 UIKit 0x2319ea10 0x22ffe000 + 1706512
6 UIKit 0x23041c58 0x22ffe000 + 277592
7 UIKit 0x2303ca62 0x22ffe000 + 256610
8 UIKit 0x2300d870 0x22ffe000 + 63600
9 UIKit 0x237a8998 0x22ffe000 + 8038808
10 UIKit 0x237a25de 0x22ffe000 + 8013278
11 CoreFoundation 0x1df1c716 0x1de5f000 + 775958
12 CoreFoundation 0x1df1c220 0x1de5f000 + 774688
13 CoreFoundation 0x1df1a4f6 0x1de5f000 + 767222
14 CoreFoundation 0x1de6952e 0x1de5f000 + 42286
15 CoreFoundation 0x1de6933c 0x1de5f000 + 41788
16 GraphicsServices 0x1f640bf8 0x1f637000 + 39928
17 UIKit 0x230789a2 0x22ffe000 + 502178
18 UIKit 0x230730cc 0x22ffe000 + 479436
19 DreamDemo 0x000bf332 main + 29490 (main.m:15)
20 libdyld.dylib 0x1d633506 0x1d630000 + 13574
可以明显的发现,系统库的堆栈变成了一堆地址。
新版本,每当我们手机连上 Xcode 时,都会把当前版本的系统符号库自动导入到/用户/用户名称xxx/资源库/Developer/Xcode/iOS DeviceSupport目录下。但是 iOS 版本那么多,之前旧的系统符号库该怎么获取呢?有人已经整理好了 iOS-System-Symbols,我们只需要根据.crash文件的版本信息,下载对应的系统符号化文件到目录下即可。
利用 symbolicatecrash 解析,可以将整个.crash日志堆栈解析,但是由于依赖symbolicatecrash、.crash以及.dSYM三个文件,或者.app、.crash及symbolicatecrash三个文件,导致不太灵活。
利用atos命令只需要.crash和.dSYM,或者.crash和.app,知道对应的堆栈地址,就能解析,方便自动化脚本分析,但是 crash 堆栈可能需要自己实现收集。