iOS 開發之EXC_BAD_ACCESS異常分析

標籤：

一：EXC_BAD_ACCESS異常介紹
在調試objective-c程式的過程中，程式crash的現象在所難免，但大部分的錯誤都能夠通過顯示的錯誤原因結合NSLog的方式來解決，比如NSInvalidArgumentException（名字就能看出來是什麼錯誤）等，實在搞不定還有debug這個殺手鐧。但唯獨EXC_BAD_ACCESS這個異常太難處理了，名字看不出來是什麼原因，其他提示也沒有，debug都搞不定。
先來介紹下EXC_BAD_ACCES：這個異常基本上是記憶體使用量不當造成的，而且90%的錯誤來源在於對一個已經釋放的對象進行release操作。

二：分析方法
為工程運行時加入 NSZombieEnabled 環境變數，並設為啟用，則在 EXC_BAD_ACCESS 發生時，XCode 的 Console 會列印出問題描述。並同時添加MallocStackLogging和MallocStackLoggingNoCompact兩個環境變數，來啟用malloc記錄

 

三：輸出資訊
只要添加了NSZombieEnabled變數，在發生EXC_BAD_ACCESS會在concole中列印出錯誤原因，絕大多數都會出現這個資訊

ok，很顯然，問題是來源就是對一個已經釋放的對象進行release操作（這裡就是HotCategoryViewController了）這樣基本上可以定位出來是在哪裡出現了錯誤，錯誤的對象是什麼，但在很多情況下，這還不夠。接下來還有一招，在concole裡面通過gdb的調試命令來看下當前執行個體從alloc到free的整個生命週期的調用過程在concole裡面敲：shell malloc_history App_PID Object_instance對應我們的例子為：2011-10-27 15:12:40.061 iAliexpress[177:707] *** -[HotCategoryViewController setTitle:]: message sent to deallocated instance 0x3a89c0這裡就應該輸入：shell malloc_history 177 0x3a89c0其中App_PID為當前的進程號（若你是用模擬器調試，沒問題;若你是用真機調試，抱歉，你看到的進程號是手機裡的，你這裡拿來沒用），Object_instance為該執行個體對象的id。斷行符號後你會得到這樣的資訊
 
最後，希望列印出來的資訊能對你有協助（大多數情況下能幫你定位問題） 轉自：http://www.1000phone.net/thread-6921-1-2.html 

（轉）iOS 開發之EXC_BAD_ACCESS異常分析