On Sep 13, 2010, at 20:34, Jeffrey Oleander wrote:
> After my main NSDocument algorithm method was done doing its thing and
> returned up the call chain to where the button click had started its action,
> it would flip to showing NSPopAutoreleasePool and I was crashing with
> EXC_BAD_ACCESS. So, I looked at all of my alloc, initWith..., retain, and
> releases. I did find a couple things which I should have been releasing, but
> had not, but no obvious ones I had been releasing that I should not have been.
> NSZombies says:
> 2010-09-13 22:47:33.575 DijkstraCocoa[511] *** *** Selector 'release' sent to
> dealloced instance 0x593180 of class NSIdEnumerator.
> Break at '-[_NSZombie release]' to debug.
> 2010-09-13 22:47:33.575 DijkstraCocoa[511] *** -[NSAutoreleasePool dealloc]:
> Exception ignored while releasing an object in an autorelease pool:
> NSGenericException *** Selector 'release' sent to dealloced instance 0x593180
> of class NSIdEnumerator.
> Break at '-[_NSZombie release]' to debug.
>
> 0x90adb928 <+0000> mr r5,r3
> 0x90adb92c <+0004> mr r3,r4
> 0x90adb930 <+0008> b 0x90adb580 <logMessageAndRaise>
>
> 0 -[_NSZombie release]
> 1 NSPopAutoreleasePool
> 2 _NSAppleEventManagerGenericHandler
> 3 aeDispatchAppleEvent(AEDesc const*, A...
> 4 dispatchEventAndSendReply(AEDesc cor...
> 5 aeProcessAppleEvent
> 6 AEProcessAppleEvent
> 7 _DPSNextEvent
> 8 -[NSApplication nextEventMatchingMask:untilDate:i...
> 9 -[NSApplication run]
> 10 NSApplicationMain
> 11 main
> What I'm wondering is how do I go about tracking down which enumerator is
> causing the problems? I'm not explicitly using autorelease pools of my own.
At the risk of sounding rude, I'd suggest you'll get more effective help on
this list if you are a little more specific in your questions. Vagueness ("my
main NSDocument algorithm method was done doing its thing" -- what does that
even mean?) and dumping too much information into your post (how does it help
you or us to include disassembly of Apple-supplied frameworks functions?)
discourages others even from reading it, let alone responding.
In this case, your symptoms *appear* very straightforward. You have
over-released an object (a NSIdEnumerator, whatever that is, since it's not a
public class) which is otherwise autoreleased. Because of the autorelease, the
point at which the exception occurs is deferred from the offending source code
to the point at which the autorelease pool is drained. At the time of the
exception, it's far too late to debug the problem directly.
Assuming that NSIdEnumerator is in fact a concrete subclass of NSEnumerator,
examining your code for ways it uses enumerators may be the most efficient way
to proceed. However, it's also possible that the enumerator object is something
internal to another object's actions (your code appears to have been servicing
an apple event), so it's also possible that an over-release of a higher level
object may be the cause of your problem, and NSIdEnumerator is only
accidentally the place where the problem first shows up.
If careful examination of your code doesn't prove fruitful, you might try using
Instruments to debug the problem. From the address of the object at the time of
the exception, Instruments can tell you where in your application the object
was originally allocated, and that will probably tell you why it was allocated,
and from there you can start asking yourself questions like, "How long does
this object need to stay alive, and what's keeping it alive?"
_______________________________________________
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 arch...@mail-archive.com
