在iPhone應用程序中調試EXC_BAD_ACCESS

這是我的堆棧跟蹤。我在哪裏開始弄清楚這一點？我嘗試了大量的NSLog（），我無法追蹤它。在iPhone應用程序中調試EXC_BAD_ACCESS

#0 0x94e9ced7 in objc_msgSend() 
#1 0x04936318 in ??() 
#2 0x0259b252 in __CFRunLoopDoObservers() 
#3 0x0259a65f in CFRunLoopRunSpecific() 
#4 0x02599c48 in CFRunLoopRunInMode() 
#5 0x02ae7615 in GSEventRunModal() 
#6 0x02ae76da in GSEventRun() 
#7 0x0061dfaf in UIApplicationMain() 
#8 0x000051cc in main

來源

2010-04-28 Jeff

靜態分析器報告什麼？（shift-command-A來分析）你有NSZombieEnabled集嗎？機會是你試圖訪問一個釋放的對象。 – 2010-04-28 03:25:56

我玩過NSZombieEnabled和樂器。這不是殭屍。 – Jeff 2010-04-28 04:04:43

從你的堆棧沒有什麼可以評估...請把一些代碼 – 2010-04-28 04:07:50

下面是我如何跟蹤這個。

首先，我走遍了使用的地方：

NSLog(@"%s", __PRETTY_FUNCTION__, nil);

，以獲得儘可能接近的崩潰。正如我所做的那樣，我碰巧注意到它看起來像一個對象變得不應該是空的。

在這一點上，GDB與NSZombieEnabled和儀器都報告沒有殭屍。

我將NSLog添加到我遇到問題的對象的dealloc和release方法。最後，我能夠充分理解在這些方法中添加斷點，並在每次發現堆棧跟蹤時發現該版本被autorelease池調用。

我終於明白我沒有保留我原本應該做的事。一旦我保留它，賓果，問題就解決了。

也就是說，NSZombieEnabled和樂器的建議都有助於其他一些自那時起就出現的錯誤，所以謝謝大家。

來源

2010-04-28 23:16:19 Jeff

當應用程序與該堆棧跟蹤崩潰時，打開調試控制檯。

如果崩潰是在模擬器中，鍵入：

display /s $ecx

如果設備上，鍵入：

display /s $r1

確保NSZombieEnabled是OFF當你正在做這個。

它將打印系統嘗試呼叫的方法的名稱。

這種方式的工作原理是，當它崩潰時崩潰試圖訪問一個不存在的方法。所以這個方法的名字作爲一個C字符串保存在一個寄存器中，這些行從寄存器中抓取並打印出來。

來源

2010-04-28 05:20:53

在iPhone應用程序中調試EXC_BAD_ACCESS

回答

相關問題