Re: NSUndoManager retain/release of arguments - ad infinitum
Re: NSUndoManager retain/release of arguments - ad infinitum
- Subject: Re: NSUndoManager retain/release of arguments - ad infinitum
- From: Jerry Krinock <email@hidden>
- Date: Sat, 5 Feb 2011 21:02:20 -0800
On 2011 Feb 05, at 16:37, John Bartleson wrote:
> A lot of the confusion comes about because of poor documentation.
That's one of the main reasons for using Graham's open-source GCUndoManager.
> whatever, could issue a command like "Track someObjectName". During execution, I'd see the following:
>
> (timestamp) (code location) someObjectName: allocated
> (timestamp) (code location) someObjectName: init
> (timestamp) (code location) someObjectName: retained
> (timestamp) (code location) someObjectName: released
> (timestamp) (code location) someObjectName: released
> (timestamp) (code location) someObjectName: dealloc
Maybe there is a tool, but the brute-force approach is not difficult. You can subclass the object, then override -retain, -release, -dealloc, and, if you want, -autorelease. Each method should log and invoke super. If the object is of a Cocoa class, you can do a Method Replacement on these methods instead, to get the same effect.
However only do this as a last resort, because you usually get a fire-hose of log statements due to all of the stuff going on under the hood, which is time-consuming to sort through. (Hint: Anything invoked internally by Cocoa is OK.) But I have used it two or three times last year to debug nightmare leaks and retain cycles. It's a good learning exercise in Cocoa memory management.
_______________________________________________
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