Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
- Subject: Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
- From: Quincey Morris <email@hidden>
- Date: Thu, 31 Dec 2009 12:00:47 -0800
On Dec 31, 2009, at 09:36, Jerry Krinock wrote:
> So, to solve this problem, I implemented a lockout kludge, an ivar mIsCleaningStacks, in the undo manager. Its -removeAllActions locks it out while it is removing objects from its undo and redo stacks, and if removeAllActionsWithTarget: sees this it doesn't touch them. I believe this is otherwise harmless, since these stacks are in the process of having all their objects removed anyhow.
>
> Is this a good case study in why "the only safe thing to do in your dealloc method is to release instance variables", or have I misunderstood the problem?
>
> Does a better workaround pop into anyone's mind? The crash does not occur when using Apple's NSUndoManager, which I presume must also have some workaround built into it.
Well, yes, this is the sort of thing that makes dealloc treacherous.
In fact, there might be an argument that there's a glaring bug in GCUndoManager. It *appears* to be assuming that CFArrayRemoveAllValues is an "atomic" operation (with regard to undo actions) but your stack trace shows clearly that it's not.
Similarly, copying the array in 'removeAllActionsWithTarget:' (presumably to make iteration over a mutating collection "safe") also seems flawed -- it looks like you could end up with multiple copies of the array in different states, with consequent hilarity. [However, at the source code level it might be provable that this is not an actual problem.]
You might be able to avoid the instance variable hack by making 'removeAllActions' etc atomic wrt the undo manager. Specifically, construct a new state (of having no actions) in local variables, then swap the new state into the normal instance variables, then clean up the old state (now in local variables). Or something like that.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden