Hi this is Marin - the author of Touch Code Magazine, I hope you are enjoying my tutorials and articles. Also if you need a bright iPhone developer overseas contact me - I do contract work. Here's my LinkedIn profile
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 :


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”


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/

The post was originally published on the following URL: http://www.touch-code-magazine.com/how-to-debug-exc_bad_access/




Marin Todorov

is an independent iOS developer and publisher. He's got more than 18 years of experience in a dozen of languages and platforms. This is his writing project.
» Contact    » Add Marin on Google+

  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.


  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!


  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.


  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.

  7. poker online on Friday 29, 2010

    good points and the details are more specific than elsewhere, thanks.

    – Joe

  8. iPhone Developer on Friday 29, 2010

    Cheers for the tip :)
    coming from a C# background all this retain and release is confusing me!
    This is very helpful!

  9. Ruug on Friday 29, 2010

    Hi Marin,

    This is really useful information. Unfortunately, I have not found my problem. I enabled zombies and all I see in the debugger is EXC_BAD_ACCESS.

    I know I’ve enabled it correctly because I purposely created an over released scenario. In my “fake” case I get a message like:
    *** -[MyObject retainCount]: message sent to deallocated instance 0x6682380

    Any thoughts on how to debug this further?


  10. Marin on Friday 29, 2010

    Hi Ruug,

    yeah EXC_BAD_ACCESS is quite an issue :)
    I have 4 posts about different cases you might have happening, have a look here :


    If all else fails … go old school – put a breakpoint somewhere before the code fails and step trough the code to see what’s going on man


  11. Ruug on Friday 29, 2010

    Ugh. Figured it out. I had something more complicated than this:

    NSString *it = @”blah”;
    NSLog(@”only one parameter ‘%@’ dummy %@”, it);

    which was causing the EXC_BAD_ACCESS.

    But the debugger kept pointing me to some other random locations. I basically worked backwards commenting out things until I narrowed down the real cause.

  12. Surender on Friday 29, 2010

    Thanx for such a helpful post. It really help me
    thanx again..
    keep the good work on..

  13. m4f1050 on Friday 29, 2010

    Just for anybody trying to enable Zombies in XCode 4.3 it’s under Product / Edit Scheme / Run (your app) / Diagnostics tab, next to Objective-C there is the checkbox “Enable Zombie Objects”

  14. Jeroen Beckers on Friday 29, 2010

    I’m just getting started with cocoa/objective-c and I got a lot of these errors. Almost always turned out to be something like this:
    NSLog(@”The answer to life the universe and everything: %@”, 42);

    This gives an EXC_BAD_ACCESS error since there’s no object to add to the string, only an integer. %@ has to be %d (in this case).

    (And I know that this is completely obvious if you’re experienced, but maybe this can spare another beginner a few hours of searching :) )

  15. […] How To Debug EXC_BAD_ACCESS […]