Debugging malloc_error_brek

[Jason8]

Hi:

What appears to be my last memory but is proving to be challenging. I
have my Framework setup so I can debug it, and all my tests run
sucesfully but I get this message when some of them run:

otest(3245,0xa0857fa0) malloc: *** error for object 0x132eb0: double
free
*** set a breakpoint in malloc_error_break to debug

So I added the break point as suggested:

(gdb) break malloc_error_break

And when it fins my breakpoint I get a stack trace that is no help. It
looks like something is being release from the autorelease pool that
is being setup automatically by my unit test system (built in
Objective-C stuff from Cocoa and XCode 3).

Can anyone comment on how I should tear this apart to find what is
being double freed? I'm really grasping at straws here. As I don't use
any autorelease in my code it must be something more 'automatic' that
Cocoa is doing or how I'm using it. All my releases and retains seem
in balance and I don't get any EXC_BAD_ACCESS messages - all runs
fine.

(gdb) backtrace
#0 0x96440131 in malloc_error_break ()
#1 0x9643b11f in szone_error ()
#2 0x9635f743 in szone_free ()
#3 0x918960e9 in -[NSConcreteMutableData dealloc] ()
#4 0x9186d57f in NSPopAutoreleasePool ()
#5 0x20104abe in -[SenTestCase performTest:] ()
#6 0x20104232 in -[SenTest run] ()
#7 0x20107768 in -[SenTestSuite performTest:] ()
#8 0x20104232 in -[SenTest run] ()
#9 0x20107768 in -[SenTestSuite performTest:] ()
#10 0x20104232 in -[SenTest run] ()
#11 0x201064f3 in +[SenTestProbe runTests:] ()
#12 0x0000283b in ?? ()
#13 0x00002b26 in ?? ()
#14 0x0000254e in ?? ()
#15 0x000024da in ?? ()

[Jason8]

Post by Jason8
What appears to be my last memory but is proving to be challenging. I

<snip>

FYI I was able to fix this - but never found out what was causing the
problem. I was using a framework that bridged some C (for OpenSSL) and
when I rebuild that - my problem went away. By adding a break point
to malloc_error_break I was able to glean a scrap of information that
let me to think a particular method was the problem. I then had to do
trial-and-error to eliminate sections of code to narrow the problem
down.

By no means an efficient method of debugging - if anyone knows a
better way I'm still interested in learning it.

[David Phillip Oster]

In article

Post by Jason8
What appears to be my last memory but is proving to be challenging. I
have my Framework setup so I can debug it, and all my tests run
otest(3245,0xa0857fa0) malloc: *** error for object 0x132eb0: double
free
*** set a breakpoint in malloc_error_break to debug
(gdb) break malloc_error_break
And when it fins my breakpoint I get a stack trace that is no help. It
looks like something is being release from the autorelease pool that
is being setup automatically by my unit test system (built in
Objective-C stuff from Cocoa and XCode 3).
Can anyone comment on how I should tear this apart to find what is
being double freed? I'm really grasping at straws here. As I don't use
any autorelease in my code it must be something more 'automatic' that
Cocoa is doing or how I'm using it. All my releases and retains seem
in balance and I don't get any EXC_BAD_ACCESS messages - all runs
fine.
(gdb) backtrace
#0 0x96440131 in malloc_error_break ()
#1 0x9643b11f in szone_error ()
#2 0x9635f743 in szone_free ()
#3 0x918960e9 in -[NSConcreteMutableData dealloc] ()
#4 0x9186d57f in NSPopAutoreleasePool ()
#5 0x20104abe in -[SenTestCase performTest:] ()
#6 0x20104232 in -[SenTest run] ()
#7 0x20107768 in -[SenTestSuite performTest:] ()
#8 0x20104232 in -[SenTest run] ()
#9 0x20107768 in -[SenTestSuite performTest:] ()
#10 0x20104232 in -[SenTest run] ()
#11 0x201064f3 in +[SenTestProbe runTests:] ()
#12 0x0000283b in ?? ()
#13 0x00002b26 in ?? ()
#14 0x0000254e in ?? ()
#15 0x000024da in ?? ()

This is pretty clear: You ran a unit test. After the end of the unit
test, the unit test system cleaned up the autorelease pool. Something in
that unit test called one of the [NSMutableData methods to return an
autoreleased object. Something else mistakenly released it. You can look
at the debug console log to see which unit test just ran. On Xcode's Run
menu is a sub menu: Run With Performance Tools. Leaks, or ObjectAlloc
are good ones to start with. Or, you can use the techniques in
http://developer.apple.com/technotes/tn2004/tn2124.html "Debugging
Magic" to turn on malloc checking. Either way, it will tell you the call
stack of who allocated the object that is being improperly released. You
can use conditional breakpoints to set a breakpoint on -[NSObject
release], but set a condition so the breakpoint fires only if the object
being released is a NSMutableData or even a NSMutableData of the correct
address.

You can turn on zombie checking to verify that none of your objects are
being accessed after they are deleted.