IPhone Development - EXC_BAD_ACCESS error without stack trace

Question

Here is my case: I have a tabular view showing contacts. The Add button on the navigation bar is used to load another view for entering data. This new view has images in the table header, and each table cell has either a UITextField or a UITextView. When I click Cancel, the view opens and the memory is released.

Here is my problem: When I open the Add interface, specify a value in either of the UITextField or UITextView and click Cancel to return to the parent view, I get an EXC_BAD_ACCESS error. When I track it, "Add Controller" calls dealloc correctly, but after [super dealloc], when I click Continue, it throws this error. Only this, no trace, although I use NSZombieEnabled. When I run the code using the tools, I get no errors :(

Hope I explain this problem clearly. Any pointers? Thanks.

Answer 1

The most common reason for this error is when you release the object, and some other mechanism tries to access / release / delete it later.

Whenever I get an EXC_BAD_ACCESS error EXC_BAD_ACCESS , my first recommendation is to run the code to determine which line calls it, and then look for any explicit [object release] calls that reference this object. Comment them one by one to find where you might have gone wrong (and, of course, make sure the object is correctly released later).

If the line does not help you determine which object (s) is / is causing the problem, start looking at your [object release] calls and make sure that you do not release objects too many times by accident, or freeing objects that you are not.

This leads to a good general guide on release in Objective-C:

If you own an object (select or save it), you release it. If you do not own it (came through the convenience method or someone else selected it), you will not let it go.

(Through Memory Management with Objective-C / Cocoa / iPhone , which also has some useful tips.)

Answer 2

Although this is most often the result of improper memory, it can happen for other reasons (and harder to debug than just turning on NSZombieEnabled ). For example, if you do not specify the correct number of arguments in the format string (i.e., when debugging another problem using NSLog ), you can end the stack trace even with the debug argument turned on. Fortunately, you can use GDB in Xcode to restore the stack trace to its previous state .

In the GDB console, you will see the instruction that crashed your program. Find the last successful return to failure command. It should look something like this:

 je 0x986cef35 <objc_msgSend+117> 

Pay attention to the hexadecimal value and do the following in GDB:

 set $eip = 0x986cef35 stepi where 

Now you should (hopefully) have a more informative stack trace.

Source (same as the link above)

Answer 3

Put [super dealloc] as the last statement of the dealloc method of the class. You will get this behavior if you first disable the superclass.

Answer 4

Cameron Spickert's answer is a bit dated as Xcode now uses lldb instead of gdb. The link to the original article is also dead.

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

 (lldb) thread backtrace 

This will show bt for the current thread. If you want to change the stream from which you want to get 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 the Cameron Spickert response, use the following commands:

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

Source 1

Source 2

Answer 5

A general rule of thumb is that everything you create, you need to control (save / release). Everything that comes out of the NIB, as a rule, should not be released in code.

Answer 6

The statements above that you should not release NIB objects contradict Apple: see here , which states that the objects for which you have an output must be released in dealloc, and that you must then set the object reference to zero.

Disclaimer: I am new to programming on the iPhone, although I have been programming for a long time.