iOS错误堆栈查找崩溃缘由的方法

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

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

进程信息

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

• 崩溃版本: BugHD 会记录崩溃产生的具体的 version 和 build 号，须要了解更多关于版本号管理的同窗，能够看一下浅谈 iOS 版本号。
• 崩溃总数: 记录这个缘由致使的崩溃总数。
• 发生设备: 记录遇到这一问题的设备数量。

设备型号

标识设备类型。 若是不少崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。从上图能够看出，发生崩溃的设备为 iPhone4S，iOS 操做系统为 7.1.2。

其余设备信息

错误堆栈

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

0   CoreFoundation                      0x2d6eaf9b  + 154
1   libobjc.A.dylib                     0x37f65ccf objc_exception_throw + 38
2   CoreFoundation                      0x2d621a39  + 176
3 FIR 0x000f0e97 FIR + 69271
4   UIKit                               0x2ff0c4ab  + 518
5   UIKit                               0x2ff0c269  + 24
6   UIKit                               0x3009836b  + 634
7   UIKit                               0x2ffb5d63  + 418
8   UIKit                               0x2ffb5b6d  + 44
9   UIKit                               0x2ffb5b05  + 184
10  UIKit                               0x2ff07d59  + 380
11  QuartzCore                          0x2fb8562b  + 142
12  QuartzCore                          0x2fb80e3b  + 350
13  QuartzCore                          0x2fb80ccd  + 16
14  QuartzCore                          0x2fb806df  + 230
15  QuartzCore                          0x2fb804ef  + 314
16  QuartzCore                          0x2fb7a21d  + 56
17  CoreFoundation                      0x2d6b6255  + 20
18  CoreFoundation                      0x2d6b3bf9  + 284
19  CoreFoundation                      0x2d6b3f3b  + 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  + 2

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

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/