本文由作者 @念茜 授權轉載。

為了能夠第一時間發現程序問題，應用程序需要實現自己的崩潰日志收集服務，成熟的開源項目很多，如 KSCrash，plcrashreporter，CrashKit 等。追求方便省心，對於保密性要求不高的程序來說，也可以選擇各種一條龍Crash統計產品，如 Crashlytics，Hockeyapp ，友盟，Bugly 等等。

• 是否集成越多的Crash日志收集服務就越保險？
• 自己收集的Crash日志和系統生成的Crash日志有分歧，應該相信誰？
• 為什麼有大量Crash日志顯示崩在main函數裡,但函數棧中卻沒有一行自己的代碼？
• 野指針類的Crash難定位，有何妙招來應對？

想解釋清這些問題，必須從Mach異常說起。

Mach異常與Unix信號

iOS系統自帶的 Apple’s Crash Reporter 記錄在設備中的Crash日志，Exception Type項通常會包含兩個元素： Mach異常 和 Unix信號。

Exception Type:         EXC_BAD_ACCESS (SIGSEGV)    
Exception Subtype:      KERN_INVALID_ADDRESS at 0x041a6f3

Mach異常是什麼？它又是如何與Unix信號建立聯系的？

Mach是一個XNU的微內核核心，Mach異常是指最底層的內核級異常，被定義在下 。每個thread，task，host都有一個異常端口數組，Mach的部分API暴露給了用戶態，用戶態的開發者可以直接通過Mach API設置thread，task，host的異常端口，來捕獲Mach異常，抓取Crash事件。

所有Mach異常都在host層被ux_exception轉換為相應的Unix信號，並通過threadsignal將信號投遞到出錯的線程。iOS中的 POSIX API 就是通過 Mach 之上的 BSD 層實現的。

因此，EXC_BAD_ACCESS (SIGSEGV)表示的意思是：Mach層的EXC_BAD_ACCESS異常，在host層被轉換成SIGSEGV信號投遞到出錯的線程。既然最終以信號的方式投遞到出錯的線程，那麼就可以通過注冊signalHandler來捕獲信號:

signal(SIGSEGV,signalHandler);

捕獲Mach異常或者Unix信號都可以抓到crash事件，這兩種方式哪個更好呢？

優選Mach異常，因為Mach異常處理會先於Unix信號處理發生，如果Mach異常的handler讓程序exit了，那麼Unix信號就永遠不會到達這個進程了。轉換Unix信號是為了兼容更為流行的POSIX標准(SUS規范)，這樣不必了解Mach內核也可以通過Unix信號的方式來兼容開發。

小貼士:

因為硬件產生的信號(通過CPU陷阱)被Mach層捕獲，然後才轉換為對應的Unix信號；蘋果為了統一機制，於是操作系統和用戶產生的信號(通過調用kill和pthread_kill)也首先沉下來被轉換為Mach異常，再轉換為Unix信號。

Crash收集的實現思路

正如上述所說，可以通過捕獲Mach異常、或Unix信號兩種方式來抓取crash事件，於是總結起來實現方案就一共有3種。

1）Mach異常方式

2）Unix信號方式

signal(SIGSEGV,signalHandler);

3）Mach異常+Unix信號方式

Github上多數開源項目都采用的這種方式，即使在優選捕獲Mach異常的情況下，也放棄捕獲EXC_CRASH異常，而選擇捕獲與之對應的SIGABRT信號。著名開源項目plcrashreporter在代碼注釋中給出了詳細的解釋：

We still need to use signal handlers to catch SIGABRT in-process. The kernel sends an EXC_CRASH mach exception to denote SIGABRT termination. In that case, catching the Mach exception in-process leads to process deadlock in an uninterruptable wait. Thus, we fall back on BSD signal handlers for SIGABRT, and do not register for EXC_CRASH.

另外，需要重點說明的是：對於應用級異常NSException，還需要特殊處理。

你是否見過崩潰在main函數的crash日志，但是函數棧裡面沒有你的代碼：

Thread 0 Crashed:
0       libsystem_kernel.dylib          0x3a61757c   __semwait_signal_nocancel + 0x18
1       libsystem_c.dylib               0x3a592a7c   nanosleep$NOCANCEL + 0xa0
2       libsystem_c.dylib               0x3a5adede   usleep$NOCANCEL + 0x2e
3       libsystem_c.dylib               0x3a5c7fe0   abort + 0x50
4       libc++abi.dylib                 0x398f6cd2   abort_message + 0x46
5       libc++abi.dylib                 0x3990f6e0   default_terminate_handler() + 0xf8
6       libobjc.A.dylib                 0x3a054f62   _objc_terminate() + 0xbe
7       libc++abi.dylib                 0x3990d1c4   std::__terminate(void (*)()) + 0x4c
8       libc++abi.dylib                 0x3990cd28   __cxa_rethrow + 0x60
9       libobjc.A.dylib                 0x3a054e12   objc_exception_rethrow + 0x26
10      CoreFoundation                  0x2f7d7f30   CFRunLoopRunSpecific + 0x27c
11      CoreFoundation                  0x2f7d7c9e   CFRunLoopRunInMode + 0x66
12      GraphicsServices                0x346dd65e   GSEventRunModal + 0x86
13      UIKit                           0x32124148   UIApplicationMain + 0x46c
14      XXXXXX                          0x0003b1f2   main + 0x1f2
15      libdyld.dylib                   0x3a561ab4   start + 0x0

可以看出是因為某個NSException導致程序Crash的，只有拿到這個NSException，獲取它的reason，name，callStackSymbols信息才能確定出問題的程序位置。

/* NSException Class Reference */
@property(readonly, copy) NSString *name;  
@property(readonly, copy) NSString *reason;
@property(readonly, copy) NSArray *callStackSymbols;
@property(readonly, copy) NSArray *callStackReturnAddresses;

方法很簡單，可通過注冊NSUncaughtExceptionHandler捕獲異常信息:

static void my_uncaught_exception_handler (NSException *exception) {
    //這裡可以取到 NSException 信息
}
NSSetUncaughtExceptionHandler(&my_uncaught_exception_handler);

將拿到的NSException細節寫入Crash日志，精准的定位出錯程序位置：

Application Specific Information:
*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key key.'
Last Exception Backtrace:
0 CoreFoundation 0x2f8a3f7e     __exceptionPreprocess + 0x7e
1 libobjc.A.dylib 0x3a054cc     objc_exception_throw + 0x22
2 CoreFoundation 0x2f8a3c94     -[NSException raise] + 0x4
3 Foundation 0x301e8f1e         -[NSObject(NSKeyValueCoding) setValue:forKey:] + 0xc6
4 DemoCrash 0x00085306          -[ViewController crashMethod] + 0x6e
5 DemoCrash 0x00084ecc          main + 0x1cc
6 DemoCrash 0x00084cf8          start + 0x24

那麼，是不是收到了大量crash在main函數卻沒有NSException信息的日志，就代表自己集成的Crash日志收集服務沒有注冊NSUncaughtExceptionHandler呢？不一定，還有另外一種可能，就是被同時存在的其他Crash日志收集服務給坑了。

多個Crash日志收集服務共存的坑

是的，在自己的程序裡集成多個Crash日志收集服務實在不是明智之舉。通常情況下，第三方功能性SDK都會集成一個Crash收集服務，以及時發現自己SDK的問題。當各家的服務都以保證自己的Crash統計正確完整為目的時，難免出現時序手腳，強行覆蓋等等的惡意競爭，總會有人默默被坑。

1）拒絕傳遞 UncaughtExceptionHandler

如果同時有多方通過NSSetUncaughtExceptionHandler注冊異常處理程序，和平的作法是：後注冊者通過NSGetUncaughtExceptionHandler將先前別人注冊的handler取出並備份，在自己handler處理完後自覺把別人的handler注冊回去，規規矩矩的傳遞。不傳遞強行覆蓋的後果是，在其之前注冊過的日志收集服務寫出的Crash日志就會因為取不到NSException而丟失Last Exception Backtrace等信息。（P.S. iOS系統自帶的Crash Reporter不受影響）

在開發測試階段，可以利用 fishhook 框架去hookNSSetUncaughtExceptionHandler方法，這樣就可以清晰的看到handler的傳遞流程斷在哪裡，快速定位污染環境者。不推薦利用調試器添加符號斷點來檢查，原因是一些Crash收集框架在調試狀態下是不工作的。

檢測代碼示例：

static NSUncaughtExceptionHandler *g_vaildUncaughtExceptionHandler;
static void (*ori_NSSetUncaughtExceptionHandler)( NSUncaughtExceptionHandler * );
void my_NSSetUncaughtExceptionHandler( NSUncaughtExceptionHandler * handler)
{
    g_vaildUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
    if (g_vaildUncaughtExceptionHandler != NULL) {
        NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
    }
    
    ori_NSSetUncaughtExceptionHandler(handler);
    NSLog(@"%@",[NSThread callStackSymbols]);
    
    g_vaildUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
    NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
}

對於越獄插件注入應用進程內部，惡意覆蓋NSSetUncaughtExceptionHandler的情況，應用程序本身處理起來比較弱勢，因為越獄環境下操作時序的玩法比較多權利比較大。

2）Mach異常端口換出+信號處理Handler覆蓋

和NSSetUncaughtExceptionHandler的情況類似，設置過的Mach異常端口和信號處理程序也有可能被干掉，導致無法捕獲Crash事件。

3）影響系統崩潰日志准確性

應用層參與收集Crash日志的服務方越多，越有可能影響iOS系統自帶的Crash Reporter。由於進程內線程數組的變動，可能會導致系統日志中線程的Crashed 標簽標記錯位，可以搜索abort()等關鍵字來復查系統日志的准確性。

若程序因NSException而Crash，系統日志中的Last Exception Backtrace信息是完整准確的，不會受應用層的胡來而影響，可作為排查問題的參考線索。

ObjC野指針類的Crash

收集Crash日志這個步驟沒有問題的情況下，還是有很多全系統棧的日志的情況，沒有自己一行代碼，分析起來十分棘手，ObjC野指針類的Crash正是如此，這裡推薦幾篇好文章：

• 如何定位Obj-C野指針隨機Crash(一)：先提高野指針Crash率
• 如何定位Obj-C野指針隨機Crash(二)：讓非必現Crash變成必現
• 如何定位Obj-C野指針隨機Crash(三)：加點黑科技讓Crash自報家門
• 分析objc_msgSend()處崩潰的小技巧

除此之外，在Crash日志中補充記錄一些額外信息可以輔助定位，如切面標記線程出處、隊列出處，記錄用戶操作軌跡等等……

版權申明：本文在微信公眾平台的發表權，已「獨家代理」給 iOS 開發（iOSDevTips）微信公共帳號。