Pimpy
How to debug EXC_BAD_ACCESS

You have to accept the fact that sooner or later you will need to debug a EXC_BAD_ACCESS problem and most probably won’t be easy to.

This article however is about how to make the process easier, in some cases easy as a piece of cake.

What does EXC_BAD_ACCESS mean?

EXC_BAD_ACCESS means that message was sent to a point in the memory where there’s no instance of a class to execute it. Thus “bad access”

When EXC_BAD_ACCESS happen?

You will get EXC_BAD_ACCESS in 3 cases:

  1. An object is not initialized
  2. An object is already released
  3. Something else that is not very likely to happen

That’s already a good starting point. Start using the debugger, if you recently added a new object to the class you’re working on, put a breakpoint at the line before the freshly added object is used for the first time and check the values in the debugger.

What’s happening most though is that you will be sending a message to an overreleased object – i.e. object that is gone from the call stack. In this cases everything (and indeed everything) you will get in the console will be just :

EXC_BAD_ACCESS.

This is because the object is gone, there is no information what class was it, or what source file or anything else. That’s really tough to debug with NSLog … NSLog is helpful, but you need to put 1,000 NSLogs around to fetch where is the problem.

Enabling NSZombies

The solution to overreleased objects are the zombies. When this feature is enabled, a dummy object (a zombie) is kept on the place of every released object, thus allowing to debug objects which were released already. Very easy to enable:

  1. Double click your executable in the “Executables” in XCode
  2. Open “Arguments” tab
  3. In “Variables to be set in the environment” (that’s the list at the bottom, be careful which one you edit) click the “+” button and for name of the variable enter “NSZombieEnabled” and for value “YES”

Voila!

Now instead of wondering what’s going on and which exact object produced the problem, you’ll see exactly which class is the trouble maker, and you’ll debug it quite fast.

Beware the zombies though

Just a reminder not to leave the zombies enabled, when you submit your app to the App store. Also, it’s a good practice to disable them if you don’t really need them.

Image: http://blog.underplot.com/photogallery/14/


 
If you liked this article please share it with your friends or colleagues; there's also a low traffic RSS feed to give you heads up when there's a new post in Touch Code Magazine.

Marin Todorov

is a programmer with some 18 years of experience in a dozen of languages, most recently fascinated about Objective-C and Cocoa Touch on the iPhone and iPad.
» Marin's homepage    » Personal blog    » Pimpy for iPhone

  1. [...] I described in last months “How to debug EXC_BAD_ACCESS” there are very few reasons for an application to fail with EXC_BAD_ACCESS, but the problem [...]

  2. Sreejit on Friday 29, 2010

    Hi Marin,

    Thanks for this post. It helped me a lot. A LOT. I had been struggling with the EXEC_BAD_ACCESS for almost 4 hours before looking to this post (via google) . I solved the bug within a couple of minutes after enabling NSZombieEnabled.

    Thanks a lot.

    -Sreejit

  3. Marin on Friday 29, 2010

    Hey Sreejit,

    great you had it solved and did left me feedback :) Totally what makes me write on this site!

    Marin

  4. Pete on Friday 29, 2010

    Hi Marin,

    Just found this page after hours of fighting with an EXC_BAD_ACCESS bug and unsuccessfully trying to find where it was happening. Like Sreejit, read this, enabled NSZombie and almost instantly found the problem.

    Thanks for the help.

    Pete

  5. Marin on Friday 29, 2010

    Hi Pete, I’m absolutely thrilled that the article is useful :) Very much appreciate you comment

  6. Vesa on Friday 29, 2010

    Hi Marlin,

    This is very useful piece of information.
    I, too, spent many hours finding the problem and fixed it under a minute with NSZombies.