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

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

崩潰捕獲

對于崩潰捕獲,以前在 移動端監控體系之技術原理剖析 中詳細闡述過,并且給出了相應的 Demo,崩潰主要是由于 Mach 異常、Objective-C 異常(NSException)引起的,同時對于 Mach 異常,到了 BSD 層會轉換為對應的 Signal 信號,那么我們也可以通過捕獲信號,來捕獲 Crash 事件。針對 NSException 可以通過注冊 NSUncaughtExceptionHandler 捕獲異常信息。下圖摘自阿里百川,簡潔明了的展現了客戶端崩潰分析架構。

沖突

在我們自己研發 Crash 收集框架之前,最早肯定都會接入網易云捕、騰訊 Bugly、Fabric 等第三方日志框架來進行崩潰的收集和分析。如果多個 Crash 收集框架存在時,往往會存在沖突。

不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題,正確的做法應該是先判斷是否有前者已經注冊了 handler,如果有則應該把這個 handler 保存下來,在自己處理完自己的 handler 之后,再把這個 handler 拋出去,供前面的注冊者處理。這里給出相應的 Demo,Demo 由@zerygao提供。

typedef void (*SignalHandler)(int signo, siginfo_t *info, void *context);

static SignalHandler previousSignalHandler = NULL;

+ (void)installSignalHandler {
    struct sigaction old_action;
    sigaction(SIGABRT, NULL, &old_action);
    if (old_action.sa_flags & SA_SIGINFO) {
        previousSignalHandler = old_action.sa_sigaction;
    }

    LDAPMSignalRegister(SIGABRT);
    // .......

}
static void LDAPMSignalRegister(int signal) {
    struct sigaction action;
    action.sa_sigaction = LDAPMSignalHandler;
    action.sa_flags = SA_NODEFER | SA_SIGINFO;
    sigemptyset(&action.sa_mask);
    sigaction(signal, &action, 0);
}
static void LDAPMSignalHandler(int signal, siginfo_t* info, void* context) {
    //  獲取堆棧,收集堆棧
    ........

    LDAPMClearSignalRigister();

    // 處理前者注冊的 handler
    if (previousSignalHandler) {
        previousSignalHandler(signal, info, context);
    }
}

上面的是一個處理 Signal handler 沖突的大概代碼思路,下面是 NSException handler 的處理思路,兩者大同小異。

static NSUncaughtExceptionHandler *previousUncaughtExceptionHandler;

static void LDAPMUncaughtExceptionHandler(NSException *exception) {
    // 獲取堆棧,收集堆棧
    // ......
    //  處理前者注冊的 handler
    if (previousUncaughtExceptionHandler) {
        previousUncaughtExceptionHandler(exception);
    }
}

+ (void)installExceptionHandler {
    previousUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
    NSSetUncaughtExceptionHandler(&LDAPMUncaughtExceptionHandler);
}

堆棧收集

你可以直接用系統的方法獲取當前線程堆棧,也可以使用 PLCrashRepoter 獲取所有線程堆棧,也可以參考 BSBacktraceLogger 自己寫一套輕量級的堆棧采集框架。

堆棧符號解析

堆棧符號化還原有四種常見的方法:

  • symbolicatecrash
  • mac 下的 atos 工具
  • linux 下的 atos 的替代品 atosl
  • 通過 dSYM 文件提取地址和符號的對應關系,進行符號還原

以上方案都有對應的應用場景,對于線上的 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,只有當崩潰日志的 UUID 與 dSYM 的 UUID 一致時,才能得到正確的解析結果。

dSYM 的 UUID 獲取方法:

xcrun dwarfdump --uuid <dSYM文件>

應用內獲取 UUID 的方法:

#import <mach-o/ldsyms.h>

NSString *executableUUID()
{
    const uint8_t *command = (const uint8_t *)(&_mh_execute_header + 1);
    for (uint32_t idx = 0; idx < _mh_execute_header.ncmds; ++idx) {
        if (((const struct load_command *)command)->cmd == LC_UUID) {
            command += sizeof(struct load_command);
            return [NSString stringWithFormat:@"%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X",
                    command[0], command[1], command[2], command[3],
                    command[4], command[5],
                    command[6], command[7],
                    command[8], command[9],
                    command[10], command[11], command[12], command[13], command[14], command[15]];
        } else {
            command += ((const struct load_command *)command)->cmdsize;
        }
    }
    return nil;
}

系統庫符號化

上面只是提取到了我們應用中 dSYM 中的符號表,對于系統庫還是無能為力的,比如 UIKit 就沒有辦法將其地址符號化,想要將動態庫符號化,需要先獲取系統庫的符號文件。提取系統符號文件可以從 iOS 固件中獲取,也可以從 Github 上開源項目中找到對應系統的符號文件。

剛才只是講了一個思路,具體的細節可以參考下面的資料:

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,333評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,491評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,263評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,946評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,708評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,186評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,255評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,409評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,939評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,774評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,976評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,518評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,209評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,641評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,872評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,650評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,958評論 2 373

推薦閱讀更多精彩內容

  • [這是第14篇] 序: iOS Crash問題是iOS開發中難以忽視的存在,本文就捕獲iOS Crash、Cras...
    南華coder閱讀 9,914評論 21 116
  • 本文就捕獲iOS Crash、Crash日志組成、Crash日志符號化、異常信息解讀、常見的Crash五部分介紹。...
    xukuangbo_閱讀 1,591評論 0 0
  • 前言 iOS崩潰是讓iOS開發人員比較頭痛的事情,app崩潰了,說明代碼寫的有問題,這時如何快速定位到崩潰的地方很...
    齊滇大圣閱讀 65,400評論 29 443
  • 前言 崩潰是讓發人員比較頭痛的事情,app崩潰了,說明代碼寫的有問題,這時如何快速定位到崩潰的地方很重要。調試階段...
    進無盡閱讀 2,046評論 0 9
  • 匕首輕晃 盡露寒光 伸出手掌 置于刃上 張口輕唱 洗滌悲傷 刀刃冰涼 壓迫心臟 刺入胸膛 渙散目光 血濺衣裳 不太...
    暗燁無殤閱讀 281評論 0 0