iPhone Development - EXC_BAD_ACCESS error with no stack trace

Question

Here\'s my case: I have a table view showing contacts. Add button in the navigation bar is used to load another view for data entry. This new view has images in table header

Answer 1

Put the [super dealloc] as the last statement of the class dealloc method. You'll get this behavior when you dealloc the super class first.

Answer 2

The general rule of thumb is that anything you create, you need to manage (retain/release). Anything that comes out of a NIB, should generally not be released in code.

Answer 3

The statements above that you should not release NIB objects are contradicted by Apple: see here, where it says that objects for which you have an outlet should be released in dealloc, and also that you should make sure to set the object reference to nil afterwards.

Disclaimer: I'm an iPhone programming newbie, though have been programming for a long time.

Answer 4

Cameron Spickert's answer is a little deprecated, since Xcode uses lldb now instead of gdb. The link to the source article is also dead.

The same thing can be done rather simply with the following lldb command:

(lldb) thread backtrace

This will show the bt for the current thread. If you want to change the thread from which you want to get the bt, select the frame and get it like this:

(lldb) thread list
(lldb) thread select 2
(lldb) thread backtrace

If you want to replicate the exact behavior of Cameron Spickert's answer, use the following commands:

(lldb) expr unsigned int $eip = 0x1979c81d4
(lldb) stepi
(lldb) thread backtrace

Source 1

Source 2

Answer 5

The most common cause of this error is when you release an object and some other mechanism tries to access/release/dealloc it later.

Whenever I get a report of an EXC_BAD_ACCESS error, my first recommendation is to step through the code to determine which line is causing it, and then to search for any explicit [object release] calls that reference that object. Comment them out one-by-one to find where you may have gone wrong (and, of course, make sure the object is properly released later).

If the line doesn't help you figure out which object(s) is/are causing the problem, start looking through your [object release] calls, and make sure you aren't releasing objects too many times by accident, or releasing objects you don't own.

This leads to a good general guideline regarding release in Objective-C:

If you own an object (allocate or retain it), you release it. If you don't own it (came via convenience method or someone else allocated it), you don't release it.

(Via Memory Management with Objective C / Cocoa / iPhone, which also has some good tips.)

Answer 6

Although this is most often a result of mismanaged memory, it can happen for other reasons (and be harder to debug than simply turning on NSZombieEnabled). For example, if you fail to supply the correct number of arguments to a format string (i.e. while debugging another problem with NSLog), you could end up with no stack trace even with all debugging arguments enabled. Luckily, you can use GDB within Xcode to restore the stack trace to a previous state.

In the GDB console you should see the instruction that crashed your program. Locate the last successful return instruction before the one that failed. It should look something like this:

je    0x986cef35 <objc_msgSend+117>

Note the hex value and execute the following in GDB:

set $eip = 0x986cef35
stepi
where

You should (hopefully) have a more informative stack trace now.

Source (same as the link above)