views:

1279

answers:

6

When I set NSZombieEnabled = Yes nothing is written to the console. How can I fix this? Or can you advise me any other tools for an EXC_BAD_ACCESS?

+6  A: 

"EXC_BAD_ACCESS" is not necessarily related to a zombie instance. It can be linked an access to an undefined reference, like a local variable.

NSArray *array;
[array objectAtIndex:0]; // <- Will throw an error

Edit: NSZombie flag will only help you to solve the "EXC_BAD_ACCESS" triggered by the use of a de-allocated instance.

In order to solve the bugs, you have to use the crash backtrace to pinpoint the location that is wrong. Then, go backward into your code and check every assignment and allocations.

Laurent Etiemble
A: 

NSArray *array; [array objectAtIndex:0]; // <- Will throw an error

I wrote it. error is EXC_BAD_ACCESS again but nszombie didn't write a message to log.

onur
Laurent is saying that there are instances where you can get an EXC_BAD_ACCESS without having an overreleased object (which is where NSZombieEnabled comes into play). You have a different bug.
Ben Gottlieb
Also, please use the comment function when talking about other answers - don't make your own answer to reply.
Tim
Sorry about replying,i didn't see add comment button.How can i solve the bug.
onur
You need more than 50 rep to comment.
Jergason
+3  A: 

Is you search Stack Overflow for EXC_BAD_ACCESS, you'll find a number of people with the same problem that you have. The vast majority of the time that you hit this, you are encountering memory issues. If you are following the protocol described here or here, and you're not seeing any reports of messages being sent to released objects on the console, it might be something different.

Have you tried starting the application in the debugger (Run | Debug - Breakpoints On)? As soon as you hit the EXC_BAD_ACCESS, the debugger should halt. If you look at the backtrace displayed in the debugger (Run | Debugger), it might show you where the error occurred.

Brad Larson
+15  A: 

You have a plain old crash. EXC_BAD_ACCESS means that your application has tried to access a memory address that is invalid. While the most typical reason for this in a non-GC'd objective-c application is messaging an object after deallocation, something that Zombie Mode detects, this particular crash can happen any number of other ways (as demonstrated).

Since your application is crashing, you should have a backtrace. You need to post that backtrace here for any of us to be able to help you further.

As Brad said, run your application with debugging enabled. In Xcode, you'll find the "Run/Debug" menu item under the "Run" menu. Use that one. When your application crashes, you should see a stack trace in the upper left corner of the debugger window.

No, really, they do show up in the debugger. A picture is worth 1,000 words. alt text

bbum
This gets my vote for 'Most Unhelpful Answer to a Newbie'. Every newbie like myself knows that plain old EXC_BAD_ACCESS errors do *not* show up in the debugger window, in any case not in a way that is understandable by or helpful to mortals. If they did, the volume of posts on CocoaDev or StackOverflow would easily be half of what they are. (Okay, I exaggerate, three-quarters).
Elise van Looij
EXC_BAD_ACCESS is a crash, plain and simple. The debugger catches said crash and displays exactly where it happened. Why it happened in the first place may not be as clear as in that picture.
bbum
love the filename (but this is a helpful screenshot +1)
Rob Fonseca-Ensor
+1 for great answer (wish I could +2 for `0x42`)
Dave DeLong
@Rob I create an average of 2 to 5 throwaway projects a day in /tmp/, thus the source of the name. :)
bbum
Excellent answer. Also, by the end of the day, I have at least three throwaway projects, named DeleteMe1-3 to remind me to clear them out later...
rcw3
That's why I make 'em in /tmp/ -- they are eventually pruned automatically.
bbum
@bbum so is fdfkdjkdfjjdfk sequential?
Rob Fonseca-Ensor
+2  A: 

Also make sure you initialize all pointers to nil before using them!

If you use a pointer without initializing it to nil or any other object, you are propably going to end up accessing memory which isn't yours.

For example the following code will also give an EXC_BAD_ACCESS which is not traceable using the NSZombieEnabled flag caused by the last line.

RecordingLocation* closest;

//find the closest recording location
for (...)
{
    //try to find the closest object...
    //suppose we don't find anything so closest is never set.
}

if (closest!=nil)
    NSLog(@"Closest: %f,%f",closest.x,closest.y);
xastor
A: 

As I just spent a happy 20 minutes staring at this with NSZombieEnabled not working, I thought I'd add this will cause a EXC_BAD_ACCESS

NSArray *arr = [NSArray arrayWithObjects:@"@dog","@cat",nil];

Note the missing '@' on the second param. I didn't :-)

Dan Bennett