views:

9505

answers:

7

Hello

I'm programming an application in Objective-C and I'm getting this error:

MyApp(2121,0xb0185000) malloc: *** error for object 0x1068310: double free
*** set a breakpoint in malloc_error_break to debug

It is happening when I release an NSAutoreleasePool and I can't figure out what object I'm releasing twice.

How do I set his breakpoint?

Is there a way to know what is this "object 0x1068310"?

thanks in advance

Gonso

A: 

In Xcode, click left of the line number to set a breakpoint. Then you can launch it by doing a "Build and Debug".

It is recommended to not have object that you create be autorelease since memory is a commodity on the iPhone. Apple recommends explicitly calling release.

Benny Wong
+6  A: 

You'll find out what the object is when you break in the debugger. Just look up the call stack and you will find where you free it. That will tell you which object it is.

The easiest way to set the breakpoint is to:

  1. Goto Run -> Show -> Breakpoints (Alt-Command-B)
  2. Scroll to the bottom of the list and add the symbol malloc_error_break
Frank Krueger
I tried that, but I get: unable to dissamble malloc_error_break.... what does it mean?
gonso
No help for autorelease double free. He needs Zombies
Roger Nolan
@gonso — Just curious, if this didn't work for you, why did you you accept it as the answer?
Quinn Taylor
Good point, Quinn.
Shaggy Frog
+15  A: 
Quinn Taylor
+2  A: 

Open up the debugger console by pressing Cmd+Shift+R. There, type

break malloc_error_break

to set a breakpoint at the beginning of the malloc_error_break function.

If you want to find out what object is located at address 0x1068310, you can type the following into the debugger console:

print-object 0x1068310

Of course, you have to do this while the object is still alive -- if the object has already been freed by the time you do this, then this will not work.

Adam Rosenfield
This is autorelease, he needs Zombies.
Roger Nolan
Finally what I did was invoking the "suspicious" method outside of AutoreleasePoll. Funny thought I still got the warning, but no break point was hit. I just commented out blocks until I found the line. I was autoreleasing a string that was created with stringWithFormat (no alloc or copy).Thank you all for your tips!Gonso
gonso
For this particular type of bug, breaking on malloc_error_break has never helped find the problem — it has always required enabling zombies.
Quinn Taylor
A: 

To find these kinds of memory and pointer problems in general, you want to run your code against a runtime memory error checker like Valgrind. This should be able to point out lots of things your code is doing wrong, beyond those that cause it to crash.

Valgrind can work on OSX (though it says it's "unsupported and incomplete and buggy"), and with a little hacking someone got it to work on iPhone SDK executables.

Even better you can try Instruments, which is part of XCode. There's a tutorial for running it here.

Jared Oberhaus
instruments is the way to go; use the object alloc instrument and turn on zombies. (or just use the Zombies template).Valgrind is solution of last resort. It is terribly slow and often simply won't work.
bbum
I agree, much better choice.
Jared Oberhaus
+1  A: 
Martijn Thé