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

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

liebiao.png
liebiao.png

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

进程信息

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

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

设备型号

shebei.png
shebei.png

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

其他设备信息

qita.png
qita.png

错误堆栈

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

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。具体用哪个,可以参考对应模块的动态库信息中确定。

猜你喜欢

转载自fir-im.iteye.com/blog/2200297