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 (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
