EXC_BAD_ACCESS signal received

When deploying the application to the device, the program will quit after a few cycles with the following error:

Program received signal: "EXC_BAD_ACCESS".

The program runs without any issue on the iPhone simulator, it will also debug and run as long as I step through the instructions one at a time. As soon as I let it run again, I will hit the EXC_BAD_ACCESS signal.

In this particular case, it happened to be an error in the accelerometer code. It would not execute within the simulator, which is why it did not throw any errors. However, it would execute once deployed to the device.

Most of the answers to this question deal with the general EXC_BAD_ACCESS error, so I will leave this open as a catch-all for the dreaded Bad Access error.

EXC_BAD_ACCESS is typically thrown as the result of an illegal memory access. You can find more information in the answers below.

Have you encountered the EXC_BAD_ACCESS signal before, and how did you deal with it?

29.11.2008 02:50:26

From your description I suspect the most likely explanation is that you have some error in your memory management. You said you've been working on iPhone development for a few weeks, but not whether you are experienced with Objective C in general. If you've come from another background it can take a little while before you really internalise the memory management rules - unless you make a big point of it.

Remember, anything you get from an allocation function (usually the static alloc method, but there are a few others), or a copy method, you own the memory too and must release it when you are done.

But if you get something back from just about anything else including factory methods (e.g. [NSString stringWithFormat]) then you'll have an autorelease reference, which means it could be released at some time in the future by other code - so it is vital that if you need to keep it around beyond the immediate function that you retain it. If you don't, the memory may remain allocated while you are using it, or be released but coincidentally still valid, during your emulator testing, but is more likely to be released and show up as bad access errors when running on the device.

The best way to track these things down, and a good idea anyway (even if there are no apparent problems) is to run the app in the Instruments tool, especially with the Leaks option.

25.02.2015 12:30:13
I had some accelerometer sampling code that was not vital to my app, which after removal, eliminated the bad access error. Which makes sense considering the simulator does not have an accelerometer. I do find it weird that this code existed, untouched, for a week before causing this error...
Héctor Ramos 30.11.2008 00:31:30
I am new to Objective-C so most of my problems should arise from memory management. After a few years in C++, I've been using mostly Java for the last three or four years so I've gotten rusty on memory management. Thanks for your answer!
Héctor Ramos 30.11.2008 00:32:24
No problem - glad you fixed it. The memory management is not really hard to get on top of - you just need make sure you learn the rules and get into good habits.
philsquared 30.11.2008 01:14:29
The problem I've had seems to be exclusively with being too aggressive in releasing strings (and such) that I create. I'm still not 100% sure on what should be released and when, but Phil's answer certainly helped.
pluckyglen 26.05.2009 04:37:15
If I followed that correctly, cmculloh, yes that was the right thing to do. You do not own the object return from objectAtIndex.
philsquared 11.09.2009 12:17:58

An EXC_BAD_ACCESS signal is the result of passing an invalid pointer to a system call. I got one just earlier today with a test program on OS X - I was passing an uninitialized variable to pthread_join(), which was due to an earlier typo.

I'm not familiar with iPhone development, but you should double-check all your buffer pointers that you're passing to system calls. Crank up your compiler's warning level all the way (with gcc, use the -Wall and -Wextra options). Enable as many diagnostics on the simulator/debugger as possible.

29.11.2008 04:08:40

In my experience, this is generally caused by an illegal memory access. Check all pointers, especially object pointers, to make sure they're initialized. Make sure your MainWindow.xib file, if you're using one, is set up properly, with all the necessary connections.

If none of that on-paper checking turns anything up, and it doesn't happen when single-stepping, try to locate the error with NSLog() statements: sprinkle your code with them, moving them around until you isolate the line that's causing the error. Then set a breakpoint on that line and run your program. When you hit the breakpoint, examine all the variables, and the objects in them, to see if anything doesn't look like you expect.I'd especially keep an eye out for variables whose object class is something you didn't expect. If a variable is supposed to contain a UIWindow but it has an NSNotification in it instead, the same underlying code error could be manifesting itself in a different way when the debugger isn't in operation.

29.11.2008 22:49:35

NSAssert() calls to validate method parameters is pretty handy for tracking down and avoiding passing nils as well.

30.11.2008 14:39:46

Not a complete answer, but one specific situation where I've received this is when trying to access an object that 'died' because I tried to use autorelease:

netObjectDefinedInMyHeader = [[[MyNetObject alloc] init] autorelease];

So for example, I was actually passing this as an object to 'notify' (registered it as a listener, observer, whatever idiom you like) but it had already died once the notification was sent and I'd get the EXC_BAD_ACCESS. Changing it to [[MyNetObject alloc] init] and releasing it later as appropriate solved the error.

Another reason this may happen is for example if you pass in an object and try to store it:

myObjectDefinedInHeader = aParameterObjectPassedIn;

Later when trying to access myObjectDefinedInHeader you may get into trouble. Using:

myObjectDefinedInHeader = [aParameterObjectPassedIn retain];

may be what you need. Of course these are just a couple of examples of what I've ran into and there are other reasons, but these can prove elusive so I mention them. Good luck!

28.10.2011 21:18:18

I've been debuging, and refactoring code to solve this error for the last four hours. A post above led me to see the problem:

Property before: startPoint = [[DataPoint alloc] init] ; startPoint= [DataPointList objectAtIndex: 0];
. . . x = startPoint.x - 10; // EXC_BAD_ACCESS

Property after: startPoint = [[DataPoint alloc] init] ; startPoint = [[DataPointList objectAtIndex: 0] retain];


16.05.2009 19:35:56
I made similar mistake. I forgot to reain the instance which caused crash and I spent hours to figure it out. Your experience lit me to find out mine. Thanks!
David.Chu.ca 12.04.2010 04:19:02

I've been debuging, and refactoring code to solve this error for the last four hours. A post above led me to see the problem:

Property before:

startPoint = [[DataPoint alloc] init] ;
startPoint= [DataPointList objectAtIndex: 0];
x = startPoint.x - 10; // EXC_BAD_ACCESS

Property after:

startPoint = [[DataPoint alloc] init] ;
startPoint = [[DataPointList objectAtIndex: 0] retain];


Thank you so much for your answer. I've been struggling with this problem all day. You're awesome!

23.12.2009 12:39:03
Aren't you just immediately overwriting startPoint? I don't think you need that first line at all.
toxaq 24.09.2010 05:36:03
There is absolutely no need to allocate and initialise a variable if you're immediately going to overwrite it with another. You're just leaking the object in the first assignment.
dreamlax 19.10.2010 20:35:56

A major cause of EXC_BAD_ACCESS is from trying to access released objects.

To find out how to troubleshoot this, read this document: DebuggingAutoReleasePool

Even if you don't think you are "releasing auto-released objects", this will apply to you.

This method works extremely well. I use it all the time with great success!!

In summary, this explains how to use Cocoa's NSZombie debugging class and the command line "malloc_history" tool to find exactly what released object has been accessed in your code.


Running Instruments and checking for leaks will not help troubleshoot EXC_BAD_ACCESS. I'm pretty sure memory leaks have nothing to do with EXC_BAD_ACCESS. The definition of a leak is an object that you no longer have access to, and you therefore cannot call it.

UPDATE: I now use Instruments to debug Leaks. From Xcode 4.2, choose Product->Profile and when Instruments launches, choose "Zombies".

23.07.2013 09:50:46
That sidenote is very important. Leaks can't cause EXC_BAD_ACCESS (they have other problems). I wrote this to try to clear up misconceptions about EXC_BAD_ACCESS loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
Lou Franco 23.07.2010 11:57:12
That zombies tool in Xcode is brilliant! I found the culprit in 3 min not hours.
Aram Kocharyan 2.03.2012 04:50:34
above link in answer in not available. Shows 404 not found error.
Tejas 3.01.2017 12:00:53

Just to add another situation where this can happen:

I had the code:

NSMutableString *string;
[string   appendWithFormat:@"foo"];

Obviously I had forgotten to allocate memory for the string:

NSMutableString *string = [[NSMutableString alloc] init];
[string   appendWithFormat:@"foo"];

fixes the problem.

23.07.2009 11:07:06
This doesn't cause any error for me because string gets initialized to nil and using the null object pattern calling a method on nil does nothing.
Liron Yahdav 14.11.2014 18:28:35

Hope you're releasing the 'string' when you're done!

24.08.2009 02:04:38

I just spent a couple hours tracking an EXC_BAD_ACCESS and found NSZombies and other env vars didn't seem to tell me anything.

For me, it was a stupid NSLog statement with format specifiers but no args passed.

NSLog(@"Some silly log message %@-%@");

Fixed by

NSLog(@"Some silly log message %@-%@", someObj1, someObj2);
26.10.2009 03:59:07

I find it useful to set a breakpoint on objc_exception_throw. That way the debugger should break when you get the EXC_BAD_ACCESS.

Instructions can be found here DebuggingTechniques

19.08.2014 22:32:08

I just had this problem. For me the reason was deleting a CoreData managed object ans trying to read it afterwards from another place.

10.12.2009 14:38:15

I forgot to return self in an init-Method... ;)

9.02.2010 11:54:40
This should be a compile time warning/error and not an EXC_BAD_ACCESS during runtime.
stigi 29.07.2014 09:03:15

Use the simple rule of "if you didn't allocate it or retain it, don't release it".

17.02.2010 08:15:14
Expand that rule by "...copy it..." and you should be fine.
Till 26.06.2012 19:53:25

Forgot to take out a non-alloc'd pointer from dealloc. I was getting the exc_bad_access on my rootView of a UINavigationController, but only sometimes. I assumed the problem was in the rootView because it was crashing halfway through its viewDidAppear{}. It turned out to only happen after I popped the view with the bad dealloc{} release, and that was it!

"EXC_BAD_ACCESS" [Switching to process 330] No memory available to program now: unsafe to call malloc

I thought it was a problem where I was trying to alloc... not where I was trying to release a non-alloc, D'oh!

28.10.2011 21:18:53

Just to add

Lynda.com has a fantastic DVD called

iPhone SDK Essential Training

and Chapter 6, Lesson 3 is all about EXEC_BAD_ACCESS and working with Zombies.

It was great for me to understand, not just the error code but how can I use Zombies to get more info on the released object.

5.04.2010 11:16:18

This is an excellent thread. Here's my experience: I messed up with the retain/assign keyword on a property declaration. I said:

@property (nonatomic, assign) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, assign) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, assign) IBOutlet UISwitch *asiaSwitch;

where I should have said

@property (nonatomic, retain) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, retain) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, retain) IBOutlet UISwitch *asiaSwitch;
3.05.2010 00:50:31
Strange, why would you need to retain IBOutlet? Their management is done for you automagically.
jv42 13.01.2011 16:09:29

I encountered EXC_BAD_ACCESS on the iPhone only while trying to execute a C method that included a big array. The simulator was able to give me enough memory to run the code, but not the device (the array was a million characters, so it was a tad excessive!).

The EXC_BAD_ACCESS occurred just after entry point of the method, and had me confused for quite a while because it was nowhere near the array declaration.

Perhaps someone else might benefit from my couple of hours of hair-pulling.

28.06.2010 12:49:07


Check out the link above and do as it says.... Just some quick instructions for using NSZombies

Run the application and after it fails (Should display "Interrupted" rather than "EXC_BAD_ACCESS"... check the Console (Run > Console)... there should be a message there now telling what object it was trying to access.


15.09.2010 19:13:09

The 2010 WWDC videos are available to any participants in the apple developer program. There's a great video: "Session 311 - Advanced Memory Analysis with Instruments" that shows some examples of using zombies in instruments and debugging other memory problems.

For a link to the login page click HERE.

19.10.2010 20:31:36

To check what the error might be

Use NSZombieEnabled.

To activate the NSZombieEnabled facility in your application:

Choose Project > Edit Active Executable to open the executable Info window. Click Arguments. Click the add (+) button in the “Variables to be set in the environment” section. Enter NSZombieEnabled in the Name column and YES in the Value column. Make sure that the checkmark for the NSZombieEnabled entry is selected.

I found this answer on iPhoneSDK

23.02.2011 16:52:22

I realize this was asked some time ago, but after reading this thread, I found the solution for XCode 4.2: Product -> Edit Scheme -> Diagnostics Tab -> Enable Zombie Objects

Helped me find a message being sent to a deallocated object.

14.02.2012 04:46:51

XCode 4 and above, it has been made really simple with Instruments. Just run Zombies in Instruments. This tutorial explains it well: debugging exc_bad_access error xcode instruments

18.06.2013 05:02:51

Don't forget the @ symbol when creating strings, treating C-strings as NSStrings will cause EXC_BAD_ACCESS.

Use this:

@"Some String"

Rather than this:

"Some String"

PS - typically when populating contents of an array with lots of records.

24.05.2013 04:55:38

Even another possibility: using blocks in queues, it might easily happen that you try to access an object in another queue, that has already been de-allocated at this time. Typically when you try to send something to the GUI. If your exception breakpoint is being set at a strange place, then this might be the cause.

29.11.2012 09:07:48

Another method for catching EXC_BAD_ACCESS exceptions before they happen is the static analyzer, in XCode 4+.

Run the static analyzer with Product > Analyze (shift+cmd+B). Clicking on any messages generated by the analyzer will overlay a diagram on your source showing the sequence of retains/releases of the offending object.

enter image description here

26.12.2012 19:15:18

I got it because I wasn't using[self performSegueWithIdentifier:sender:] and -(void) prepareForSegue:(UIstoryboardSegue *) right

21.01.2013 23:52:10

How i deal with EXC_BAD_ACCESS

Sometimes i feel that when a EXC_BAD_ACCESS error is thrown xcode will show the error in the main.m class giving no extra information of where the crash happens(Sometimes).

In those times we can set a Exceptional Breakpoint in Xcode so that when exception is caught a breakpoint will be placed and will directly intimate the user that crash has happened in that line

enter image description here

7.01.2014 09:17:17

When you have infinite recursion, I think you can also have this error. This was a case for me.

13.04.2014 19:36:05