Carbon in Cocoa Crashing: EXC_BAD_ACCESS after NSAutoreleasePool is released

I'm developing a Cocoa user interface for a Photoshop CS3 plugin using Bindings. (Carbon in Cocoa, since PS is a Carbon app) I'm getting a EXC_BAD_ACCESS error when I close my modal NSWindow and the NSAutoreleasePool releases.

I believe it has something to do with bindings and the control views I have in my nib file, because when I remove the bindings from the check boxes and radio buttons from the nib, the window can close an unlimited number of times and not crash.

I've spent hours now with Instruments trying to figure out which object might be getting released early (or double released) and cannot find it.

Now my thoughts are that maybe there is something I'm missing about running a modal window within an NSAutoreleasePool while using Cocoa Bindings. Like maybe there is something I'm supposed to do before closing the window to "finalize" all the bindings to prevent them from sending messages to released objects.

Here is a basic code example of what I'm doing:

NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];    
NSApplicationLoad();
ExportWindowController *controller = [[ExportWindowController alloc开发者_如何学Python] initWithWindowNibName:EXPORT_CONTROLLER_NIB_NAME];

[controller showWindow:nil];
[NSApp runModalForWindow:[controller window]];
[controller close];

[controller release];
[localPool release];

The modal window is closed by a call to:

[NSApp stopModal];

Here is a stack trace:

#0  0x97793869 in _cache_getMethod
#1  0x9779c6da in lookUpMethod
#2  0x97793da7 in _class_lookupMethodAndLoadCache
#3  0x97793953 in objc_msgSend
#4  0x96501151 in -[NSBinder releaseConnectionWithSynchronizePeerBinders:]
#5  0x96a10390 in -[NSValueBinder releaseConnectionWithSynchronizePeerBinders:]
#6  0x963ac895 in -[NSObject(_NSBindingAdaptorAccess) _releaseBindingAdaptor]
#7  0x964062f5 in -[NSView _releaseBindingAdaptor]
#8  0x96405784 in -[NSView _finalizeWithReferenceCounting]
#9  0x96404e2f in -[NSView dealloc]
#10 0x964ef163 in -[NSControl dealloc]
#11 0x9099a9d8 in CFRelease
#12 0x909c75bd in _CFAutoreleasePoolPop
.... more

Turning on NSZombieEnabled did not turn up any double-released objects (although there was 1 from Photoshop itself)

Turning off all bindings gets rid of any crash.

Any ideas?

---

You are correct that the bindings seem to be causing the problem as the stack crawl indicates. However, I think that is just the symptom, not the problem.

As you are aware, Cocoa in a Carbon application can be tricky.

When you write, "the ExportWindowController runModalWindowForExport is this:" am I to understand these points:

1. ExportWindowController is a class based off of NSWindowController?

2. If so, when do you dismiss the window? I see [self close] but, I don't see any "close" selector associated with NSWindowController. Should you be calling:

   [[controller window] performClose:[NSApplication sharedApplication]];
   

? 3. Also, is NSApp instantiated? Do you see your window? I've had to use [NSApplication sharedApplication] to get it working right sometimes....

Let me know if any of this helps.

EDIT: Nov 6, 2009: 16:15 EST: What happens if you have only one Cocoa binding? Are you releasing the data that the binding is bound to first? Perhaps you shouldn't be if so...

EDIT: Nov 9, 2009: 16:27 EST:I was recently working in a plug-in that works with a Carbon application. This plug-in is using Cocoa as its basis. Everything was going splendidly until I added NSTrackingAreas to my NSControls. Then I started seeing all sorts of crashes when the plug-in's NSAutorelease pool was being drained. I solved this problem by calling each NSControl's removeTrackingArea function.

Perhaps you need to do something similar for your NSWindowController based object? In the dealloc selector, try calling code to removeObserver:forKeyPath on each object that you have a binding to?

---

If it is crashing when the NSAutoreleasePool is being drained, it is because something is being over-released. You should be able to turn on Zombie detection to figure out what; to find the type of the object being over-released.

At a complete guess, do you implement a -dealloc method in ExportWindowController? If so, are you -releaseing an object that was created by the NIB load for which a -retain did not occur upon load?