iOS異常捕獲

標籤：

文章目錄

 

一. 系統Crash

二. 處理signal

• 下面是一些訊號說明

• 關鍵點注意

三. 實戰

四. Crash Callstack分析 – 進?一步分析

五. demo地址

六. 參考文獻

 

前言

 

今天在ios進階群，有朋友問到iOS的異常捕捉的問題，這一塊以前也沒有研究過，趁此機會研究了一把。並寫了一個demo，如有需要可以在文章最下面去下載。

 

在閱讀文章之前，建議大家在閱讀完此篇文章後可以閱讀漫談iOS Crash收集架構，瞭解一下原理。

 

開發iOS應用，解決Crash問題始終是一個難題。Crash分為兩種，一種是由EXC_BAD_ACCESS引起的，原因是訪問了不屬於本進程的記憶體位址，有可能是訪問已被釋放的記憶體；另一種是未被捕獲的Objective-C異常（NSException），導致程式向自身發送了SIGABRT訊號而崩潰。其實對於未捕獲的Objective-C異常，我們是有辦法將它記錄下來的，如果日誌記錄得當，能夠解決絕大部分崩潰的問題。這裡對於UI線程與後台線程分別說明

 

一. 系統Crash

 

對於系統Crash而引起的程式異常退出，可以通過UncaughtExceptionHandler機制捕獲；也就是說在程式中catch以外的內容，被系統內建的錯誤處理而捕獲。我們要做的就是用自訂的函數替代該ExceptionHandler即可。

 

二. 處理signal

 

使用Objective-C的異常處理是不能得到signal的，如果要處理它，我們還要利用unix標準的signal機制，註冊SIGABRT, SIGBUS, SIGSEGV等訊號發生時的處理函數。該函數中我們可以輸出棧資訊，版本資訊等其他一切我們所想要的。

 

下面是一些訊號說明

 

1) SIGHUP

本訊號在使用者終端串連(正常或非正常)結束時發出, 通常是在終端的控制進程結束時, 通知同一session內的各個作業, 這時它們與控制終端不再關聯。

登入Linux時，系統會分配給登入使用者一個終端(Session)。在這個終端啟動並執行所有程式，包括前台進程組和後台進程組，一般都屬於這個 Session。當使用者退出Linux登入時，前台進程組和後台有對終端輸出的進程將會收到SIGHUP訊號。這個訊號的預設操作為終止進程，因此前台進 程組和後台有終端輸出的進程就會中止。不過可以捕獲這個訊號，比如wget能捕獲SIGHUP訊號，並忽略它，這樣就算退出了Linux登入， wget也 能繼續下載。

此外，對於與終端脫離關係的守護進程，這個訊號用於通知它重新讀取設定檔。

 

2) SIGINT

程式終止(interrupt)訊號, 在使用者鍵入INTR字元(通常是Ctrl-C)時發出，用於通知前台進程組終止進程。

 

3) SIGQUIT

和SIGINT類似, 但由QUIT字元(通常是Ctrl-)來控制. 進程在因收到SIGQUIT退出時會產生core檔案, 在這個意義上類似於一個程式錯誤訊號。

 

4) SIGILL

執行了非法指令. 通常是因為可執行檔本身出現錯誤, 或者試圖執行資料區段. 堆疊溢位時也有可能產生這個訊號。

 

5) SIGTRAP

由斷點指令或其它trap指令產生. 由debugger使用。

 

6) SIGABRT

調用abort函數產生的訊號。

 

7) SIGBUS

非法地址, 包括記憶體位址對齊(alignment)出錯。比如訪問一個四個字長的整數, 但其地址不是4的倍數。它與SIGSEGV的區別在於後者是由於對合法儲存地址的非法訪問觸發的(如訪問不屬於自己儲存空間或唯讀儲存空間)。

 

8) SIGFPE

在發生致命的算術運算錯誤時發出. 不僅包括浮點運算錯誤, 還包括溢出及除數為0等其它所有的算術的錯誤。

 

9) SIGKILL

用來立即結束程式的運行. 本訊號不能被阻塞、處理和忽略。如果管理員發現某個進程終止不了，可嘗試發送這個訊號。

 

10) SIGUSR1

留給使用者使用

 

11) SIGSEGV

試圖訪問未分配給自己的記憶體, 或試圖往沒有寫入權限的記憶體位址寫資料.

 

12) SIGUSR2

留給使用者使用

 

13) SIGPIPE

管道破裂。這個訊號通常在處理序間通訊產生，比如採用FIFO(管道)通訊的兩個進程，讀管道沒開啟或者意外終止就往管道寫，寫進程會收到SIGPIPE訊號。此外用Socket通訊的兩個進程，寫進程在寫Socket的時候，讀進程已經終止。

 

14) SIGALRM

時鐘定時訊號, 計算的是實際的時間或時鐘時間. alarm函數使用該訊號.

 

15) SIGTERM

程式結束(terminate)訊號, 與SIGKILL不同的是該訊號可以被阻塞和處理。通常用來要求程式自己正常退出，shell命令kill預設產生這個訊號。如果進程終止不了，我們才會嘗試SIGKILL。

 

17) SIGCHLD

子進程結束時, 父進程會收到這個訊號。

如果父進程沒有處理這個訊號，也沒有等待(wait)子進程，子進程雖然終止，但是還會在核心進程表中佔有表項，這時的子進程稱為殭屍進程。這種情 況我們應該避免(父進程或者忽略SIGCHILD訊號，或者捕捉它，或者wait它派生的子進程，或者父進程先終止，這時子進程的終止自動由init進程 來接管)。

 

18) SIGCONT

讓一個停止(stopped)的進程繼續執行. 本訊號不能被阻塞. 可以用一個handler來讓程式在由stopped狀態變為繼續執行時完成特定的工作. 例如, 重新顯示提示符

 

19) SIGSTOP

停止(stopped)進程的執行. 注意它和terminate以及interrupt的區別:該進程還未結束, 只是暫停執行. 本訊號不能被阻塞, 處理或忽略.

 

20) SIGTSTP

停止進程的運行, 但該訊號可以被處理和忽略. 使用者鍵入SUSP字元時(通常是Ctrl-Z)發出這個訊號

 

21) SIGTTIN

當後台作業要從使用者終端讀資料時, 該作業中的所有進程會收到SIGTTIN訊號. 預設時這些進程會停止執行.

 

22) SIGTTOU

類似於SIGTTIN, 但在寫終端(或修改終端模式)時收到.

 

23) SIGURG

有”緊急”資料或out-of-band資料到達socket時產生.

 

24) SIGXCPU

超過CPU時間資源限制. 這個限制可以由getrlimit/setrlimit來讀取/改變。

 

25) SIGXFSZ

當進程企圖擴大檔案以至於超過檔案大小資源限制。

 

26) SIGVTALRM

虛擬時鐘訊號. 類似於SIGALRM, 但是計算的是該進程佔用的CPU時間.

 

27) SIGPROF

類似於SIGALRM/SIGVTALRM, 但包括該進程用的CPU時間以及系統調用的時間.

 

28) SIGWINCH

視窗大小改變時發出.

 

29) SIGIO

檔案描述符準備就緒, 可以開始進行輸入/輸出操作.

 

30) SIGPWR

Power failure

 

31) SIGSYS

非法的系統調用。

 

關鍵點注意

 

• 在以上列出的訊號中，程式不可捕獲、阻塞或忽略的訊號有：SIGKILL,SIGSTOP

• 不能恢複至預設動作的訊號有：SIGILL,SIGTRAP

• 預設會導致進程流產的訊號有：SIGABRT,SIGBUS,SIGFPE,SIGILL,SIGIOT,SIGQUIT,SIGSEGV,SIGTRAP,SIGXCPU,SIGXFSZ

• 預設會導致進程退出的訊號有:

• SIGALRM,SIGHUP,SIGINT,SIGKILL,SIGPIPE,SIGPOLL,SIGPROF,SIGSYS,SIGTERM,SIGUSR1,SIGUSR2,SIGVTALRM

• 預設會導致進程停止的訊號有：SIGSTOP,SIGTSTP,SIGTTIN,SIGTTOU

• 預設進程忽略的訊號有：SIGCHLD,SIGPWR,SIGURG,SIGWINCH

• 此外，SIGIO在SVR4是退出，在4.3BSD中是忽略；SIGCONT在進程掛起時是繼續，否則是忽略，不能被阻塞。

 

三. 實戰

 

1.AppDelegate.m中

 

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

// Override point for customization after application launch.

    

InstallSignalHandler();//訊號量截斷

InstallUncaughtExceptionHandler();//系統異常捕獲

    

return YES;

}

 

2.SignalHandler.m的實現

 

void SignalExceptionHandler(int signal)

{

    NSMutableString *mstr = [[NSMutableString alloc] init];

    [mstr appendString:@"Stack:\n"];

    void* callstack[128];

    int i, frames = backtrace(callstack, 128);

    char** strs = backtrace_symbols(callstack, frames);

    for (i = 0; i

        [mstr appendFormat:@"%s\n", strs[i]];

    }

    [SignalHandler saveCreash:mstr];

 

}

 

void InstallSignalHandler(void)

{

    signal(SIGHUP, SignalExceptionHandler);

    signal(SIGINT, SignalExceptionHandler);

    signal(SIGQUIT, SignalExceptionHandler);

    

    signal(SIGABRT, SignalExceptionHandler);

    signal(SIGILL, SignalExceptionHandler);

    signal(SIGSEGV, SignalExceptionHandler);

    signal(SIGFPE, SignalExceptionHandler);

    signal(SIGBUS, SignalExceptionHandler);

    signal(SIGPIPE, SignalExceptionHandler);

}

 

有關錯誤類型可以看上面的說明，SignalExceptionHandler是訊號出錯時候的回調。當有訊號出錯的時候，可以回調到這個方法

 

3.UncaughtExceptionHandler.m的實現

 

void HandleException(NSException *exception)

{

    // 異常的堆棧資訊

    NSArray *stackArray = [exception callStackSymbols];

    // 出現異常的原因

    NSString *reason = [exception reason];

    // 異常名稱

    NSString *name = [exception name];

    NSString *exceptionInfo = [NSString stringWithFormat:@"Exception reason：%@\nException name：%@\nException stack：%@",name, reason, stackArray];

    NSLog(@"%@", exceptionInfo);

    [UncaughtExceptionHandler saveCreash:exceptionInfo];

}

 

void InstallUncaughtExceptionHandler(void)

{

    NSSetUncaughtExceptionHandler(&HandleException);

}

 

4.測試–踩坑關鍵

 

這裡最關鍵的一步，SignalHandler不要在debug環境下測試。因為系統的debug會優先去攔截。我們要運行一次後，關閉debug狀態。應該直接在模擬器上點擊我們build上去的app去運行。而UncaughtExceptionHandler可以在調試狀態下捕捉

 

- (IBAction)buttonClick:(UIButton *)sender {

//1.訊號量

    Test *pTest = {1,2};

    free(pTest);//導致SIGABRT的錯誤，因為記憶體中根本就沒有這個空間，哪來的free，就在棧中的對象而已

    pTest->a = 5;

}

- (IBAction)buttonOCException:(UIButton *)sender

{

    //2.ios崩潰

    NSArray *array= @[@"tom",@"xxx",@"ooo"];

    [array objectAtIndex:5];

}

 

 

 

四. Crash Callstack分析 – 進?一步分析

 

屬性	說明
0x8badf00d	在啟動、終?止應?用或響應系統事件花費過?長時間,意為“ate bad food”。
0xdeadfa11	?使用者強制退出,意為“dead fall”。(系統?無響應時,?使用者按電源開關和HOME)
0xbaaaaaad	?使用者按住Home鍵和?音量鍵,擷取當前記憶體狀態,不代表崩潰
0xbad22222	VoIP應?用因為恢複得太頻繁導致crash
0xc00010ff	因為太燙了被幹掉,意為“cool off”
0xdead10cc	因為在後台時仍然佔據系統資源(?比如通訊錄)被幹掉,意為“dead lock”

 

五. demo地址

 

iOSCrashUncaught下載

https://github.com/xcysuccess/iOSCrashUncaught

 

六. 參考文獻

 

1.程式crash後的調試技巧

2.iOS開發socket程式被SIGPIPE訊號Terminate的問題

3.美女念茜

4.如何定位Obj-C野指標隨機Crash(一)：先提高野指標Crash率

5.如何定位Obj-C野指標隨機Crash(二)：讓非必現Crash變成必現

6.如何定位Obj-C野指標隨機Crash(三)：加點黑科技讓Crash自報家門

iOS異常捕獲