On Mar 6, 2008, at 23:54, Steve Cronin wrote:

If I set the NSZombieEnabled variable to YES I get the following:
#0      0x9282b36d in -[NSException raise]
#1      0x92852247 in +[NSException raise:format:]
#2      0x928da79b in logMessageAndRaise
#3      0x927dc8af in NSPopAutoreleasePool
#4      0x932849d8 in loadNib
#5 0x932843d9 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] #6 0x9328403a in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:]
#7      0x93283f7c in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#8      0x93283cc3 in NSApplicationMain
#9      0x00405ffc in main at main.m:18
Console:
2008-03-07 01:33:24.728 XYZ[372] *** Selector 'release' sent to dealloced instance 0x1baba2c0 of class NSConcreteData.
Break at '-[_NSZombie release]' to debug.

NOTE: I do an 'API' & and a Full-Text Search in the documentation for 'NSConcreteData' and there is nothing! Not a single reference. Google yields more but NSConcreteData is definitely not used directly by my app.

The class of the the dealloced object is not *necessarily* relevant. (If the block of memory used for an object of class A was released when you still had a pointer to it, then alloced and dealloced for a transient object of class B, then if you released your pointer-to-A again, you'd get a message for the "wrong" class.)

One explanation for what you're seeing is that you've overreleased (possibly but not necessarily in your app delegate awakeFromNib) an object that was just loaded from the nib. If the nib loading code still had a retain on the object when you released it, the error might not show up till long after the spurious release.

You should carefully check your awakeFromNib methods to see if you release (directly or indirectly) something from the nib you didn't retain. Also check any initWithCoder methods for custom subclasses (e.g. of views) in your nib for similar errors, since that initializer gets called during the nib loading process for every object as it is unarchived.

(I don't think you'd go far wrong in assuming that EXC_BAD_ACCESS == "I released something I shouldn't have" unless proved otherwise. At least, that's what it has meant 99% of the times I've seen it in my debugging.)
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to