EXC_BAD_ACCESS. Debugging this one is on par with figuring out why the wife says “not tonight, honey.” And they are equally unfortunate situations.
Let’s see what we can do about EXC_BAD_ACCESS.
EXC_BAD_ACCESS happens when a message is sent to an object that has already been released. By the time the error is caught, the call stack is usually gone especially if dealing with multiple threads.
How nice would it be to keep a dummy around after the object is released that could stop execution, tell us what message was sent and show us the call stack… well, there’s a way to do just that.
If you set the NSZombieEnabled environment variable, the Objective C runtime will leave a dummy object behind for every deallocated object. When the zombie object is called, execution stops and you can see the message that was sent to the object and the call stack that tells you where the message came from (it doesn’t tell you where you over released the object, but knowing where the object is called from should get you pretty close to the problem.)
To set this variable, go to the info panel of the executable in xcode, and create a new environment variable in the arguments tab by clicking the plus sign in the lower left corner of the window. Name the variable NSZombieEnabled, type YES for the value and make sure that the checkbox is selected.
Go ahead and run your program now (in debug mode, because you need the stack information.) When the over released object is accessed, you get an error message similar to this (xcode debug view):
2009-03-30 02:30:36.172 ninjaJumper[3997:20b] *** -[GameLayer retain]: message sent to deallocated instance 0x59bf670
This shows the class of the object (GameLayer) and the message sent (retain).
Let’s take a look at the stack now:
The methods printed in bold are in your code, the others are in some other API. Here you can see that the object was accessed from [Director touchesBegan:withEvent], where an array was copied (most likely the over released object was in the array.)
This information should get you pretty close to the problem.
Once the problem is fixed, make sure that the NSZombieEnabled variable is disabled. You don’t need to delete it, but make sure that the checkbox is unchecked:
Now about the wife. Good luck there. Try a box of chocolate or load the dishwasher for a couple days.
如何調試EXC_BAD_ACCESS
文章分類:移動開發 關鍵字: exc_bad_access當程序出現“EXC_BAD_ACCESS”時，就像不解風情的妻子對你說：“親愛的，今晚不行”。這兩種情況都是非常不幸的。
讓我們先看看EXC_BAD_ACCESS到底是什麼。
向已經釋放的對象發送消息時會出現EXC_BAD_ACCESS。當出現錯誤時，通常會調用堆棧信息，特別是在多線程的情況下。
怎樣提供一個dummy，當釋放一個對象導致程序終止時，在堆棧上告訴我們錯誤信息，好，下面我們將告訴你怎麼去做。
如果你設置了NSZombiEnabled環境變量，當銷燬一個對象時，objective的運行時環境會在這個對象後邊設置一個dummy，當調用這個對象的方法時，程序會終止，並在堆棧上顯示錯誤信息，下邊教你怎麼設置NSZombiEnabled
首先，在Xcode中打開executables
查看其中內容的信息。
然後，打開信息面板中的Arguments面板
點擊左下角的加號，添加變量NSZombiEnabled，並將變量的值設置爲YES。
重新運行程序，當過度釋放對象時，會在控制檯上出現如下信息：
2009-03-30 02:30:36.172 ninjaJumper[3997:20b] *** -[GameLayer retain]: message sent
to deallocated instance 0x59bf670
說明想GameLayer的一個對象發送了retain消息
查看堆棧信息：
如何查看：http://lovebirdegg.javaeye.com/blog/550489
當問題解決後，要將NSZombieEnabled設置爲無效，不需要刪除變量，將變量前的對號去掉就可以了：
