iOS crash 日志堆栈解析

时间  2019-11-07
标签 ios crash 日志 堆栈 解析 栏目 iOS 繁體版
原文   原文链接

平常开放中，咱们不免遇到一些 crash。大部分状况下，Xcode 能够帮助咱们找到问题所在，但也有些状况，Xcode 给咱们反馈的是一些看不懂的地址，大大增长了咱们分析问题的难度。ios

下面，就来介绍几种能让看不懂的地址，变得看的懂的方式。git

symbolicatecrash

.dSYM 文件

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 目录下找就行。github

symbols 又是什么呢？

引用 《程序员的自我修养》中的解释：bash

在连接中，咱们将函数和变量统称为符号（Symbol），函数名或变量名就是符号名（Symbol Name）。咱们能够将符号看做是连接中的粘合剂，整个连接过程正是基于符号才可以正确完成。app

因此，所谓的 symbols 就是函数名或变量名。函数

找到 symbolicatecrash

symbolicatecrash 是 Xcode 自带的 crash 日志分析工具，咱们须要先找到它：工具

find /Applications/Xcode.app -name symbolicatecrash -type f
复制代码

执行完后会返回几个路径，个人是：oop

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash
复制代码

咱们到这个路径下把 symbolicatecrash 拷贝出来，放到一个文件夹下。测试

拿到 crash 日志文件

咱们能够随便写段强制 crash 的代码：

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
	NSArray *arr = @[];
	arr[100];
}
复制代码

接着用真机打个包。打好包以后，不要用 Xcode build，直接用打好的包运行咱们能致使 crash 的代码，这样就生成好 .crash 日志文件了。

以后，咱们去 Xcode -> Window -> Devices and Simulators 或者快捷键 Command + Shift + 2

找到对应时间点的 .crash 文件，右击 Export Log。

拿到 .app 文件

.app 文件可使用真机编译下，去 项目 Products 目录下获取，也能够去 Archives 目录下获取。

符号解析

利用 dSYM

将 .dSYM 、.crash 及 symbolicatecrash 放到同一个文件下，执行命令：

./symbolicatecrash .crash文件路径 .dSYM文件路径 > 名字.crash
复制代码

利用 app

将 .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
复制代码

能够发现，第三行被解析出来了，这样咱们就能很清晰的知道具体的页面了。

使用命令行工具 atos

symbolicatecrash 能够帮助咱们很好的分析 crash 日志，可是有它的局限性 --- 不够灵活。咱们须要 symbolicatecrash、.crash 及 .dSYM 三个文件才能解析。

相对于 symbolicatecrash， atos 命令更加灵活，特别是你须要对不一样渠道的 crash 文件，写一个自动化的分析脚本的时候，这个方法就极其有用。

可是这种方式也有个不方便的地方：一个线上的 App，用户使用的版本存在差别，而每一个版本所对应的 .dSYM 都是不一样的。必须确保 .crash 和 .dSYM 文件是匹配的，才能正确符号化，匹配的条件就是它们的 UUID 一致。 在这以前，先介绍下 UUID：

什么是 UUID ?

UUID 是由一组 32 位数的十六进制数字所构成。每个可执行程序都有一个 build UUID 惟一标识。.crash日志包含发生 crash 的这个应用的 build UUID 以及 crash 发生时，应用加载的全部库文件的 build UUID。

获取 UUID

.crash UUID

执行命令：

grep --after-context=2 "Binary Images:" *crash
复制代码

输出：

T.crash:Binary Images:
T.crash-0x7c000 - 0x87fff DreamDemo armv7  <d009f8671129397a8aab9cb2b8e506ff> /var/containers/Bundle/Application/DEEBE571-D512-4E8F-B712-ED4D19CE64F9/DreamDemo.app/DreamDemo
T.crash-0xa9000 - 0xd4fff dyld armv7s  <cd60ff3403063c0aa8e54dff11e42527> /usr/lib/dyld
复制代码

看到上面的输出 d009f8671129397a8aab9cb2b8e506ff 就是 DreamDemo 项目的 UUID。

.dSYM UUID

执行命令：

dwarfdump --uuid DreamDemo.app.dSYM
复制代码

输出：

UUID: D009F867-1129-397A-8AAB-9CB2B8E506FF (armv7) DreamDemo.app.dSYM/Contents/Resources/DWARF/DreamDemo
复制代码

.app UUID

执行命令：

dwarfdump --uuid DreamDemo.app/DreamDemo
复制代码

输出：

UUID: D009F867-1129-397A-8AAB-9CB2B8E506FF (armv7) DreamDemo.app/DreamDemo
复制代码

能够发现这两个文件的 UUID 是相同的，也就是匹配的，只有知足这种条件，才能正确的解析！

atos 解析

咱们现回顾下未解析前的堆栈：

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 堆栈可能须要本身实现收集。

参考

wufawei.com/2014/03/sym…

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程