你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> 漫談iOS Crash收集框架

漫談iOS Crash收集框架

編輯:IOS開發基礎

為了能夠第一時間發現程序問題,應用程序需要實現自己的崩潰日志收集服務,成熟的開源項目很多,如 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 層實現的。

1.png

因此,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.png

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日志中補充記錄一些額外信息可以輔助定位,如切面標記線程出處、隊列出處,記錄用戶操作軌跡等等……


  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved