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\".
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);
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
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.
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];
Goodbye EXC_BAD_ACCESS
Thank you so much for your answer. I've been struggling with this problem all day. You're awesome!
I just had this problem. For me the reason was deleting a CoreData managed object ans trying to read it afterwards from another place.
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.