iOS：如何捕獲異常？
前言
今天在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” |
五. 參考文獻
1.程序crash后的調試技巧
2.iOS開發socket程序被SIGPIPE信號Terminate的問題
3.美女念茜
4.如何定位Obj-C野指針隨機Crash(一)：先提高野指針Crash率
5.如何定位Obj-C野指針隨機Crash(二)：讓非必現Crash變成必現
6.如何定位Obj-C野指針隨機Crash(三)：加點黑科技讓Crash自報家門
來自：http://mobile.51cto.com/iphone-535262.htm