一：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。回車后你會得到這樣的信息
最后，希望打印出來的信息能對你有幫助（大多數情況下能幫你定位問題）