iOS內(nèi)存錯誤EXC_BAD_ACCESS的解決方法
iOS開發(fā),最郁悶的莫過于程序毫無征兆地就崩潰了,用bt命令打出調(diào)用棧,給出的是一堆系統(tǒng)EXC_BAD_ACCESS的信息,根本沒辦法定位問題出現(xiàn)在哪里。 首先說一下 EXC_BAD_ACCESS 這個錯誤,可以這么說,90%的錯誤來源在于對一個已經(jīng)釋放的對象進(jìn)行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);
}
}
通常這樣的崩潰出現(xiàn),原因一般就是:調(diào)用了已經(jīng)釋放的內(nèi)存空間,或者說重復(fù)釋放了某個地址空間。而怎樣定位到這個地址呢,可以通過編輯xcode的scheme,添加如下標(biāo)記位,讓系統(tǒng)把錯誤地址打印出來,如圖:
(通過Product->Scheme->Edit Scheme進(jìn)入下面編輯頁面,選中Arguments tab,增加標(biāo)計(jì)位NSZombieEnabled設(shè)為YES)

這樣,但崩潰出現(xiàn),系統(tǒng)會出現(xiàn)以下提示信息:
2013-06-23 00:45:20.479 *** -[__NSArrayM addObject:]: message sent to deallocated instance 0x7179910
可見崩潰原因是內(nèi)存地址0x7179910被重復(fù)釋放了。
Objective-C 這段代碼有三個致命問題:1、內(nèi)存泄露;2、錯誤釋放;3、造成 EXC_BAD_ACCESS 錯誤。
如果崩潰是發(fā)生在當(dāng)前調(diào)用棧,通過上面的做法,系統(tǒng)就會把崩潰原因定位到具體代碼中。但是,如果崩潰不在當(dāng)前調(diào)用棧,系統(tǒng)就僅僅只能把崩潰地址告訴我們,而沒辦法定位到具體代碼,這樣我們也沒法去修改錯誤。這時就可以修改scheme,讓xcode記錄每個地址alloc的歷史,這樣我們就可以用命令把這個地址還原出來。如圖:(跟設(shè)置NSZombieEnabled一樣,添加MallocStackLoggingNoCompact,并且設(shè)置為YES)

這樣,當(dāng)出現(xiàn)崩潰原因是message sent to deallocated instance 0x7179910,我們可以使用以下命令,把內(nèi)存地址還原:
info malloc-history 0x7179910
如圖,這個命令能具體把這個地址在哪一行代碼生成還原出來。

(需要注意的是,因?yàn)檫@個命令只支持gdb,所以必須把控制臺的輸出改成gdb,并且有點(diǎn)遺憾的是,只支持模擬器,不支持真機(jī)調(diào)試)

(同樣是通過Product->Scheme->Edit Scheme進(jìn)入上面編輯頁面,選中Info tab)
這樣,好好檢查一下那一行的代碼,應(yīng)該就很容易找出問題所在了。
相關(guān)文章
實(shí)例解析設(shè)計(jì)模式中的外觀模式在iOS App開發(fā)中的運(yùn)用
這篇文章主要介紹了設(shè)計(jì)模式中的外觀模式在iOS App開發(fā)中的運(yùn)用,實(shí)例代碼為傳統(tǒng)的Objective-C,需要的朋友可以參考下2016-03-03
Objective-C 實(shí)現(xiàn)2048算法類
本文給大家介紹的是使用Objective-C 實(shí)現(xiàn)的IOS版小游戲2048算法類,十分的實(shí)用,有需要的小伙伴可以參考下。2015-06-06
iOS應(yīng)用程序中通過dispatch隊(duì)列控制線程執(zhí)行的方法
Grand Central Dispatch簡稱(GCD)是蘋果公司開發(fā)的技術(shù),以優(yōu)化的應(yīng)用程序支持多核心處理器和其他的對稱多處理系統(tǒng)的系統(tǒng),iOS應(yīng)用程序中通過dispatch隊(duì)列控制線程執(zhí)行則是以并發(fā)來達(dá)到多核優(yōu)化的重要途徑.2016-05-05

