轉載：http://blog.163.com/gf_zl818/blog/static/8380806820125435918564/
論壇裏經常有朋友會問Crash的問題。Crash最多的無非就兩種，一種就是signal SIGABRT,大概的意思就是發送Message出現問題，信號迷失了。
這種的Crash其實是很好定位，Crash了後直接看Console裏出的最後日誌，比如這段：
2012-03-28 19:26:33.055 TableViewMenuDemo[3916:f803] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[__NSArrayI replaceObjectAtIndex:withObject:]: unrecognized selector sent to instance 0x6a3f3d0′
*** First throw call stack:
找到reason字段，那就是原因,說NSArray 調用 replaceObjectAtIndex:withObject：
這個方法是NSMutableArry的，NSArray並沒有該方法。信號迷失掉了，所以Crash了。0x6a3f3d0 是出問題的內存地址,查下內存地址或搜下調用方法就比較好定位了。
Xcode4上還有個更好用的定位方法，就是設置一個Exception Breakpoint就好了
看圖在工程的左邊欄中選擇Breakpoint Navigator ,點擊下面的+號添加一個Exception Breakpoint，然後再運行試試，Crash後，是不是直接定位到了那行代碼了？再根據Console裏的日誌進行定位修改就好了。
下面說說另一種Crash,EXC_BAD_ACCESS ,這個比較頭疼，因爲Crash的時候，可能是比較早之前的某個變量釋放了，現在訪問時出問題。Console裏也沒顯示什麼日誌。
這裏光加入Exception Breakpoint是不夠的了，XCode4還個可愛的地方，打開Scheme選項選擇Edit Scheme
然後按圖勾上Enable Zombie Objects 和Malloc Stack那兩項，記住一般只有在定位EXC_BAD_ACCESS時候才勾選，別有事沒事都勾上。
這樣重新跑一下，如果是到Exception Breakpoint處停止了，可以在Console中輸入：c（continue)按回車繼續跑，直到Crash。看下Console是不是有跟SIGABRT類似的錯誤信息日誌了，後面定位什麼的你懂的。
如果還沒有日誌，在Console中輸入 po $eax $eax標誌出錯的地方，適用模擬器，真機用$r0（話說EXC_BAD_ACCESS這種錯誤模擬器定位就行）,還可以輸入比如：po [$eax name] po [$eax reason]等指令查看錯誤其他信息（注意方括號後沒分號的）。然後，就沒有然後了。
還要補充點，程序開發過程就要多關注左邊欄中Issue Navigator裏的警告信息，Xcode4不僅會警告，還多數給出解決建議。能避免後面不必要的Crash
如果程序Crash，第一時間關注下debug Navigator裏的執行信息，將滑塊拉向右邊可以看到更多調用信息，根據這個能大致設想是調用什麼方法或進行什麼操作時Crash的。
好了，大致這些就能比較有效率的解決一般Crash問題。歡迎大家有獨到的經驗可以補充進來。