iOS Crash 捕獲及堆疊符號化思路剖析

最近在做 crash 分析方面的工作，發現 ios 的崩潰捕獲和堆疊符號化雖然已經有很多資料可以參考，但是沒有比較完善的成套解決方案，導致操作起來還是要踩很多坑，耽誤了很多時間。所以想做乙個總結，闡述 crash 收集分析的整體思路和出坑指南，具體細節實現會給出相關參考資料。有了思路，實現也就 so easy 啦。

對於崩潰捕獲，以前在移動端監控體系之技術原理剖析中詳細闡述過，並且給出了相應的 demo，崩潰主要是由於 mach 異常、objective-c 異常（n***ception）引起的，同時對於 mach 異常，到了 bsd 層會轉換為對應的 signal 訊號，那麼我們也可以通過捕獲訊號，來捕獲 crash 事件。針對 n***ception 可以通過註冊 nsuncaughtexceptionhandler 捕獲異常資訊。下圖摘自阿里百川，簡潔明瞭的展現了客戶端崩潰分析架構。

不管是對於 signal 捕獲還是 n***ception 捕獲都會存在 handler 覆蓋的問題，正確的做法應該是先判斷是否有前者已經註冊了 handler，如果有則應該把這個 handler 儲存下來，在自己處理完自己的 handler 之後，再把這個 handler 丟擲去，供前面的註冊者處理。這裡給出相應的 demo，demo 由@zerygao提供。

typedef void (*signalhandler)(int signo, siginfo_t *info, void *context);
static signalhandler previoussignalhandler = null;
+ (void)installsignalhandler 
ldapmsignalregister(sigabrt);
// .......
}static void ldapmsignalregister(int signal) 
static void ldapmsignalhandler(int signal, siginfo_t* info, void* context) 
}複製**

上面的是乙個處理 signal handler 衝突的大概**思路，下面是 n***ception handler 的處理思路，兩者大同小異。

static nsuncaughtexceptionhandler *previousuncaughtexceptionhandler;
static void ldapmuncaughtexceptionhandler(n***ception *exception) 
}+ (void)installexceptionhandler 複製**

你可以直接用系統的方法獲取當前執行緒堆疊，也可以使用 plcrashrepoter 獲取所有執行緒堆疊，也可以參考bsbacktracelogger自己寫一套輕量級的堆疊採集框架。

堆疊符號化還原有四種常見的方法：

以上方案都有對應的應用場景，對於線上的 crash 堆疊符號還原，主要採用的還是後三種方案。atos 和 atosl 的使用方法很類似，以下是 atos 的乙個示例。

atos -o monitorexample 0x0000000100062ac4  arm-64 -l 0x100058000
// 還原結果
-[gyrootviewcontroller tableview:cellforrowatindexpath:] (in gymonitorexample) (gyrootviewcontroller.m:41)複製**

但是 atos 是mac上乙個工具，需要使用 mac 或者黑蘋果來進行解析工作，如果由後台來做解析工作，往往需要一套基於 linux 的解析方案，這個時候可以選擇 atosl，但是這個庫已經有多年沒有更新了，同時基於我司的嘗試， atosl 好像不太支援 arm64 架構，所以我們放棄了該方案。

最終使用了第四個方案，提取 dsym 的符號表，可以自己研發工具，也可以直接使用 bugly 和網易雲捕提供的工具，下面是提取出來的符號表。第一列是起始記憶體位址，第二列是結束位址，第三列是對應的函式名、檔名以及行號。

a840 a854 -[gyrootviewcontroller tableview:cellforrowatindexpath:] gyrootviewcontroller.m:41 a854 a858 -[gyrootviewcontroller tableview:cellforrowatindexpath:] gyrootviewcontroller.m:42 a858 a87c -[gyrootviewcontroller tableview:cellforrowatindexpath:] gyrootviewcontroller.m:42 a87c a894 -[gyrootviewcontroller tableview:cellforrowatindexpath:] gyrootviewcontroller.m:42 a894 a8a0 -[gyrootviewcontroller tableview:cellforrowatindexpath:] gyrootviewcontroller.m:42 aa3c aa80 -[gyfilepreviewviewcontroller initwithfilepath:] gyrootviewcontroller.m:21 aa80 aaa8 -[gyfilepreviewviewcontroller initwithfilepath:] gyfilepreviewviewcontroller.m:23 aaa8 aab8 -[gyfilepreviewviewcontroller initwithfilepath:] gyfilepreviewviewcontroller.m:23 aab8 aabc -[gyfilepreviewviewcontroller initwithfilepath:] gyfilepreviewviewcontroller.m:24

aabc aac8 -[gyfilepreviewviewcontroller initwithfilepath:] gyfilepreviewviewcontroller.m:24複製**

因為程式每次啟動基位址都會變化，所以上面提到的位址是相對偏移位址，在我們獲取到崩潰堆疊位址後，可以根據堆疊中的偏移位址來與符號表中的位址來做匹配，進而找到堆疊所對應的函式符號。比如下面的第四行，偏移為 43072 轉換為十六進製制就是 a840，用 a840 去上面的符號表中找對應關係，會發現對應著-[gyrootviewcontroller tableview:cellforrowatindexpath:]，基於這種方式，就可以將堆疊位址完全還原為函式符號啦。

0 libsystem_kernel.dylib 0x0000000186cfd314 0x186cde000 + 127764 1 foundation 0x00000001887f5590 0x1886ec000 + 1086864 2 gymonitorexample 0x00000001000da4ac 0x1000d0000 + 42156

3 gymonitorexample 0x00000001000da840 0x1000d0000 + 43072複製**

我們的應用存在多個版本，並且支援多種不同的架構，那麼如何找到與崩潰日誌對應的符號表呢？就是依靠 uuid，只有當崩潰日誌的 uuid 與 dsym 的 uuid 一致時，才能得到正確的解析結果。

dsym 的 uuid 獲取方法：

xcrun dwarfdump --uuid 複製**

應用內獲取 uuid 的方法：

#import 
nsstring *executableuuid
() else 
}return nil;
}複製**

上面只是提取到了我們應用中 dsym 中的符號表，對於系統庫還是無能為力的，比如 uikit 就沒有辦法將其位址符號化，想要將動態庫符號化，需要先獲取系統庫的符號檔案。提取系統符號檔案可以從 ios 韌體中獲取，也可以從 github 上開源專案中找到對應系統的符號檔案。

iOS Crash 捕獲及堆疊符號化思路剖析

iOS crash 監控及解決措施

iOS crash檔案符號化不出系統方法

golang 異常退出堆疊捕獲

iOS Crash 捕獲及堆疊符號化思路剖析

iOS crash 監控及解決措施

iOS crash檔案符號化不出系統方法

golang 異常退出堆疊捕獲

相關推薦