iOS記憶體錯誤EXC

來源:互聯網
上載者:User

  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)

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

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。