iPhone Objective-C EXC_BAD_ACCESS問題

轉自:http://blog.csdn.net/diyagoanyhacker/archive/2011/05/30/6455244.aspx

寫程式遇到 Bug 並不可怕，大部分的問題，通過簡單的 Log 或者 程式碼分析並不難找到原因所在。但是在 Objective-C 編程中遇到 EXC_BAD_ACCESS 問題的時候，通過簡單常規的手段很難發現問題。

    寫程式遇到 Bug 並不可怕，大部分的問題，通過簡單的 Log 或者 程式碼分析並不難找到原因所在。但是在 Objective-C
編程中遇到 EXC_BAD_ACCESS 問題的時候，通過簡單常規的手段很難發現問題。這篇文章，給大家介紹一個常用的尋找
EXC_BAD_ACCESS 問題根源的方法。

    首先說一下 EXC_BAD_ACCESS 這個錯誤，可以這麼說，90%的錯誤來源在於對一個已經釋放的對象進行release操作。

Objective-C 這段代碼有三個致命問題：1、記憶體泄露；2、錯誤釋放；3、造成 EXC_BAD_ACCESS 錯誤。

    1， NSString* s = [[NSString alloc]initWithString:@”This is a test
string”]; 建立了一個 NSString Object，隨後的 s = [s substringFromIndex:[s
rangeOfString:@"a"].location]; 執行後，導致建立的對象引用消失，直接造成記憶體泄露。

    2，錯誤釋放。[s release]; 這個問題，原因之一是一個邏輯錯誤，以為 s 還是我們最初建立的那個 NSString
對象。第二是因為從 substringFromIndex:(NSUInteger i) 這個方法返回的 NSString
對象，並不需要我們來釋放，它其實是一個被 substringFromIndex 方法標記為 autorelease
的對象。如果我們強行的釋放了它，那麼會造成 EXC_BAD_ACCESS 問題。

    3， EXC_BAD_ACCESS。由於 s 指向的 NSString 對象被標記為 autorelease, 則在
NSAutoreleasePool 中已有記錄。但是由於我們在前面錯誤的釋放了該對象，則當 [pool drain]
的時候，NSAutoreleasePool 又一次的對它記錄的 s 對象調用了 release 方法，但這個時候 s
已經被釋放不複存在，則直接導致了 EXC_BAD_ACCESS問題。

查看更多的Console資訊

工作區->Excuteables->雙擊其分組下的檔案->Arguments設定運行參數

1: 為工程運行時加入 NSZombieEnabled 環境變數，則在 EXC_BAD_ACCESS 發生時，XCode 的 Console 會列印出問題描述。

2：加入 MallocStackLogging 來啟用malloc記錄

做如下設定：

Project -> Edit active executable ->Argument 

添加如下四個參數

NSDebugEnabled

NSZombieEnabled

MallocStackLogging 

MallocStackLoggingNoCompact