DebuggingAutorelease (set a breakpoint in malloc_error_break to debug)

 

Update: For Leopard users, I recommend using Instruments: http://www.corbinstreehouse.com/blog/index.php/2007/10/instruments-on-leopard-how-to-debug-those-random-crashes-in-your-cocoa-app/

One of the most opaque bugs I 've had to deal with in Cocoa is leaving a released object in the autorelease pool, causing an EXC_BAD_ACCESS in NSPopAutoreleasePool? (). When this happens, it's pretty much impossible to tell what the doubly-released object was and where it was instantiated.

Fear no more! Using Cocoa's NSZombie debugging class and the command-line malloc_history tool, we can nail this bug in a pinch.

Suppose you have the following (obviusly incorrect) code:

 

  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSData* data = [NSData dataWithBytes:"asklaskdxjgr" length:12];

  [data release];
  [pool release];

The dataWithBytes: method sends an autorelease message to the created object, so we don't need to release it ourselves. when the autorelease pool is tossed the freed data object gets another release message, our app crashes, and we have no idea why.

Here's what we do:

Click on the "Targets" tab, open "Executables" and select the app (In XCode 2.0, double-click the executable in the file tree and select the arguments tab to enter environment variables ). in the executable settings, add the following environment variables and set their values to "YES" (without the quotes ):

 

  NSDebugEnabled
NSZombieEnabled  MallocStackLogging

You may also want the following environment variable set to YES:

 

  MallocStackLoggingNoCompact

With NSZombieEnabled, Cocoa sets an object's isa pointer to the NSZombie class when its retain count drops to zero instead of deallocating it. then when you send a message to an NSZombie object (I. e ., you're accessing freed data), it raises an exception and tells you where the object lives:

 

  2003-03-18 13:01:38.644 autoreleasebug[3939] *** *** Selector 'release'
  sent to dealloced instance 0xa4e10 of class NSConcreteData.

Since you have MallocStackLogging turned on, you can now run "malloc_history <pid> <address>" to see the stack trace when the object was allocated:

 

  [dave@host193 Frameworks]$ malloc_history 3939 0xa4e10

  Call [2] [arg=32]: thread_a0000dec |0x1000 | start | _start | main |
  +[NSData dataWithBytes:length:] | NSAllocateObject | object_getIndexedIvars |
  malloc_zone_calloc 

If you run under gdb, you may enter:

 (gdb) shell malloc_history 3939 0xa4e10

And there it is: the double-released object was allocated with [NSData dataWithBytes: length:] in the function main ()!

I love you, Cocoa!

 

Another useful breakpoint is "szone_error"-this stops the debugger where you get the "Incorrect checksum for freed object" message

 

Also note that NSZombieEnabled keeps objects from being freed, so if you use it with MallocStackLogging you won't see premature releases. turn off NSZombieEnabled and wait for the segfault .. hopefully your debugger will still be awake and can show you the line you're crashing on.

 

What woshould a malloc_debug like this mean?

 

Call [2] [arg=24]: thread_a000a1ec |0x0 | _dyld_start | _start | main | NSApplicationMain
 | -[NSApplication run] | -[NSApplication sendEvent:] | -[NSWindow sendEvent:]
 | -[NSControl mouseDown:] | -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:]
 | -[NSCell trackMouse:inRect:ofView:untilMouseUp:] | -[NSCell _sendActionFrom:]
 | -[NSControl sendAction:to:] | -[NSApplication sendAction:to:from:] | -[MEController 
newCity:] | -[MECityEditor editCity:otherCities:] | -[NSApplication runModalForWindow:]
 | -[NSApplication _realDoModalLoop:peek:] | -[NSApplication nextEventMatchingMask:
untilDate:inMode:dequeue:] | _DPSNextEvent | BlockUntilNextEventMatchingListInMode
 | ReceiveNextEventCommon | RunCurrentEventLoopInMode | CFRunLoopRunSpecific
 | __CFRunLoopRun | __CFRunLoopDoObservers | _handleWindowNeedsDisplay | -[NSWindow 
displayIfNeeded] | -[NSView displayIfNeeded] | -[NSView _displayRectIgnoringOpacity:
isVisibleRect:rectIsVisibleRectForView:] | -[NSThemeFrame 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:
topView:] | -[NSFrameView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:
rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:
isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView(NSInternal) _getDirtyRects:clippedToRect:count:boundingBox:] | -[NSRegion 
mutableCopy] | NSAllocateObject | _internal_class_createInstanceFromZone | malloc_zone_calloc

My program does this when I select an object in a popupmenu. When I break at malloc_printf the program breaks inside NSPopAutoreleasePool ?, So I know I have an autorelease bug. This is one of several "double free" bugs I 've inheritted with code that I'm taking over

Source link

Http://www.cocoadev.com/index.pl? DebuggingAutorelease

 

Info malloc addressTo see more debug information