iOS错误堆栈查找崩溃原因的方法

作者：崔志伟
BugHD 是 FIR.im 为开发者提供的查找崩溃的工具，一些同学使用后，对于根据错误堆栈查找问题的方法还有一些疑问，现在我用一个FIR.imiOS客户端在BugHD上搜集到的崩溃做例子，带大家了解一下BugHD：

liebiao.png

我解读一下这份崩溃日志：

进程信息

*** -[__NSArrayI objectAtIndex:]: index 20 beyond bounds [0 .. 0]是闪退进程的相关信息。

• 崩溃版本: BugHD 会记录崩溃产生的具体的 version 和 build 号，需要了解更多关于版本号管理的同学，可以看一下浅谈 iOS 版本号。
• 崩溃总数: 记录这个原因导致的崩溃总数。
• 发生设备: 记录遇到这一问题的设备数量。

设备型号

shebei.png

标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。从上图可以看出，发生崩溃的设备为 iPhone4S，iOS 操作系统为 7.1.2。

其他设备信息

qita.png

错误堆栈

从错误堆栈中，你可以看到闪退发生时抛出的异常类型，也可以看到异常编码和抛出异常的线程。

<pre><code>
0 CoreFoundation 0x2d6eaf9b <redacted> + 154
1 libobjc.A.dylib 0x37f65ccf objc_exception_throw + 38
2 CoreFoundation 0x2d621a39 <redacted> + 176
<b>3 FIR 0x000f0e97 FIR + 69271</b>
4 UIKit 0x2ff0c4ab <redacted> + 518
5 UIKit 0x2ff0c269 <redacted> + 24
6 UIKit 0x3009836b <redacted> + 634
7 UIKit 0x2ffb5d63 <redacted> + 418
8 UIKit 0x2ffb5b6d <redacted> + 44
9 UIKit 0x2ffb5b05 <redacted> + 184
10 UIKit 0x2ff07d59 <redacted> + 380
11 QuartzCore 0x2fb8562b <redacted> + 142
12 QuartzCore 0x2fb80e3b <redacted> + 350
13 QuartzCore 0x2fb80ccd <redacted> + 16
14 QuartzCore 0x2fb806df <redacted> + 230
15 QuartzCore 0x2fb804ef <redacted> + 314
16 QuartzCore 0x2fb7a21d <redacted> + 56
17 CoreFoundation 0x2d6b6255 <redacted> + 20
18 CoreFoundation 0x2d6b3bf9 <redacted> + 284
19 CoreFoundation 0x2d6b3f3b <redacted> + 730
20 CoreFoundation 0x2d61eebf CFRunLoopRunSpecific + 522
21 CoreFoundation 0x2d61eca3 CFRunLoopRunInMode + 106
22 GraphicsServices 0x32578663 GSEventRunModal + 138
23 UIKit 0x2ff6b14d UIApplicationMain + 1136
24 FIR 0x000e9743 FIR + 38723
25 libdyld.dylib 0x38472ab7 <redacted> + 2
</code></pre>

以上的错误堆栈信息是闪退发生时所有活动帧清，它包含闪退发生时调用函数的清单。我们收集到的信息有三种情况:

1. 已标记错误位置的:

3   FIR        0x000000010bfddd8c -[FIRViewController viewDidLoad] + 8588

2. 未标记错误位置，有基地址的情况：

3   FIR           0x000e3e92 0xd3000 + 69266

这条调用栈包括下面四部分:

• 模块号: 这里是3
• 二进制库名: 这里是 FIR.im
• 调用方法的地址: 这里是 0x000e3e92
• 第四部分分为两列，基地址和偏移地址。此处基地址为 0xd3000，偏移地址为 69266。

使用下面的命令符号化：

atos -arch armv7 -o FIR -l 0xd3000 0x000e3e92

结果：

-[FIRViewController viewDidLoad] (FIRViewController.m:156)

可以看到崩溃的类为 FIRViewController，函数为 viewDidLoad，文件名是 FIRViewController.m，行数是 156 行。

3. 未标记错误位置，无基地址的情况：

3   FIR            0x000f0e97 FIR + 69271

基地址的计算方法:

－load address ＝ 0x000f0e97 － 69271 ＝0xe0000

使用下面的命令符号化：

atos -arch armv7 -o FIR -l 0xe0000 0x000f0e97

结果：

-[FIRViewController viewDidLoad] (FIRViewController.m:156)

可以看到崩溃的类为FIRViewController，函数为viewDidLoad，文件名是FIRViewController.m，行数是156行。

这里我们简单我们看一下 atos 用法：

atos -o dysm文件路径 -l  模块load地址 -arch cpu 指令集种类 调用方法的地址

1. dysm 文件路径：可以在 Xcode Organizer 的 Archives 标签栏下找到所有已归档的应用文件。它保存了编译过程的详细信息，其中包括符号信息。
2. 模块 load 地址：模块加载的基地址，可以在日志的动态库信息中找到对应模块的基地址。这里为 0xd3000
3. cpu 指令集种类：可以为 armv6 armv7 armv7s arm64。具体用哪个，可以参考对应模块的动态库信息中确定。

详情 http://blog.fir.im/2014/ios_crash/