讓XCode的 Stack Trace信息可讀

讓XCode的 Stack Trace信息可讀

NOV 14TH, 2012

昨天在寫iOS代碼的時候，調試的時候模擬器崩潰了。異常停在了以下整個main函數的入口處：

1 2 3 4 5 6 7

int main(int argc, char *argv[]) { @autoreleasepool { // 異常停在了下面這行，毫無提示做用 return UIApplicationMain(argc, argv, nil, NSStringFromClass([MyClass class])); } }

XCode的Console界面報出了一些出錯信息, 以下圖所示：

我根據Console裏面的文字提示信息，猜出應該是出現了空指針nil的操做。可是具體出錯在哪一行，殊不知道。最終雖然找到了bug，可是debug的過程確實費了些時間。考慮到這個stace trace信息應該對我挺有幫助纔對的，因此我就查了一下如何讓這本來一堆16進制的調用棧信息更可讀。因而在stackoverflow上找到了2個比較好的解決辦法，在這裏分享給你們。

方法一

該方法的步驟是，首先在你的AppDelegate中定義一個方法, 用於處理異常：

1 2 3 4 5

void uncaughtExceptionHandler(NSException *exception) { NSLog(@"CRASH: %@", exception); NSLog(@"Stack Trace: %@", [exception callStackSymbols]); // Internal error reporting }

而後在應用啓動時，設置這個方法做爲本身的自定義異常回調：

1 2 3 4 5

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); // Normal launch stuff }

完成以後，當對於上面的異常，在定義了這個回調以後，Log信息變成以下所示，出錯行一目瞭然，根據下面的可讀的stack trace，我一下就能夠找到是QuestionParser這個類的第378行致使的異常，進而能夠跳到出錯行分析緣由，很容易就把bug修復了。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

Ape[2711:11303] CRASH: *** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[2] Ape[2711:11303] Stack Trace: ( 0 CoreFoundation 0x0209402e __exceptionPreprocess + 206 1 libobjc.A.dylib 0x01a71e7e objc_exception_throw + 44 2 CoreFoundation 0x0205aa95 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 165 3 CoreFoundation 0x020874e9 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 73 4 Ape 0x00096a0a +[QuestionParser parseToDictionary:] + 378 5 Ape 0x00096434 -[QuestionStore putQuestion:] + 308 6 Ape 0x00089ddf -[QuestionViewController requestFinished:] + 303 7 Ape 0x000869dd -[NetworkAgent requestFinished:] + 653 8 Ape 0x00085d33 __27-[NetworkAgent addRequest:]_block_invoke_0 + 131 9 libdispatch.dylib 0x01cf153f _dispatch_call_block_and_release + 15 10 libdispatch.dylib 0x01d03014 _dispatch_client_callout + 14 11 libdispatch.dylib 0x01cf2fd6 _dispatch_after_timer_callback + 28 12 libdispatch.dylib 0x01d03014 _dispatch_client_callout + 14 13 libdispatch.dylib 0x01cfa8b7 _dispatch_source_latch_and_call + 219 14 libdispatch.dylib 0x01cf6405 _dispatch_source_invoke + 322 15 libdispatch.dylib 0x01cf3768 _dispatch_main_queue_callback_4CF + 187 16 CoreFoundation 0x0203aaf5 __CFRunLoopRun + 1925 17 CoreFoundation 0x02039f44 CFRunLoopRunSpecific + 276 18 CoreFoundation 0x02039e1b CFRunLoopRunInMode + 123 19 GraphicsServices 0x0282b7e3 GSEventRunModal + 88 20 GraphicsServices 0x0282b668 GSEventRun + 104 21 UIKit 0x00be265c UIApplicationMain + 1211 22 Ape 0x00016c5d main + 141 23 Ape 0x00002b05 start + 53 24 ??? 0x00000001 0x0 + 1 )

方法二

方法二相比方法一更加簡單，具體作法是在XCode界面中按cmd + 6跳到Breakpoint的tab，而後點擊左下角的+號，增長一個Exception的斷點，以下圖所示。這樣，當異常出現時，會自動停在異常處，而不會拋出到UIApplicationMain。拿個人有bug的程序來講，代碼會自動斷在QuestionParser這個類的第378行。

總結

其實之前XCode是能顯示出可讀的stack trace信息的，彷佛到了XCode4.2之後就出問題了。因此上面提到的2個辦法至關於walk around解決了XCode4.2之後出現的bug。若是該文章對你有用，但願你能幫我點擊下面的分享按鈕，分享給更多朋友，同時也幫我宣傳一下博客，這將有助於我分享更多的心得給你們，Have fun!