iOS開發，最郁悶的莫過于程序毫無征兆地就崩潰了，用bt命令打出調用棧，給出的是一堆系統EXC_BAD_ACCESS的信息，根本沒辦法定位問題出現在哪里。 首先說一下 EXC_BAD_ACCESS 這個錯誤，可以這么說，90%的錯誤來源在于對一個已經釋放的對象進行release操作。舉一個簡單的例子來說明吧，首先看一段Java代碼：

　　public class Test{

　　public static void main(String[] args){

　　String s = “This is a test string”;

　　s = s.substring(s.indexOf(“a”),(s.length()));

　　System.out.println(s);

　　}

　　}

　　通常這樣的崩潰出現，原因一般就是:調用了已經釋放的內存空間，或者說重復釋放了某個地址空間。而怎樣定位到這個地址呢，可以通過編輯xcode的scheme，添加如下標記位，讓系統把錯誤地址打印出來，如圖：

　　(通過Product->Scheme->Edit Scheme進入下面編輯頁面，選中Arguments tab，增加標計位NSZombieEnabled設為YES)

　　這樣，但崩潰出現，系統會出現以下提示信息：

　　2013-06-23 00:45:20.479 *** -[__NSArrayM addObject:]: message sent to deallocated instance 0x7179910

　　可見崩潰原因是內存地址0x7179910被重復釋放了。

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

　　如果崩潰是發生在當前調用棧，通過上面的做法，系統就會把崩潰原因定位到具體代碼中。但是，如果崩潰不在當前調用棧，系統就僅僅只能把崩潰地址告訴我們，而沒辦法定位到具體代碼，這樣我們也沒法去修改錯誤。這時就可以修改scheme，讓xcode記錄每個地址alloc的歷史，這樣我們就可以用命令把這個地址還原出來。如圖：(跟設置NSZombieEnabled一樣，添加MallocStackLoggingNoCompact，并且設置為YES)

　　這樣，當出現崩潰原因是message sent to deallocated instance 0x7179910，我們可以使用以下命令，把內存地址還原：

　　info malloc-history 0x7179910

　　如圖，這個命令能具體把這個地址在哪一行代碼生成還原出來。

　　(需要注意的是，因為這個命令只支持gdb，所以必須把控制臺的輸出改成gdb，并且有點遺憾的是，只支持模擬器，不支持真機調試)

　　(同樣是通過Product->Scheme->Edit Scheme進入上面編輯頁面，選中Info tab)

　　這樣，好好檢查一下那一行的代碼，應該就很容易找出問題所在了。