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/