On 10 Jan 2010, at 5:17 PM, Graham Cox wrote: > On 11/01/2010, at 11:01 AM, Paul Sanders wrote: > >> Have >> you got the energy to file an enhancement request Graham? > > Filed: #7528006 > > "It would be useful to have available the following two debugging functions: > > a) A way to test whether a given object is referenced by any current > autorelease pool. > b) A way to dump (log) the content of all current autorelease pools. > > One problem with debugging over-release issues is when an object is > deallocated but a reference to it remains in an autorelease pool. The later > pop of the pool will crash, but information about what object caused the > problem is lost unless zombies is on, and even then that tells you very > little about where the real problem lies, the answer to which will often be > found in the calling stack for the prior release that called -dealloc. > > The ability to assert on an autorelease pool holding a reference to self at > -dealloc time would be a useful weapon in the fight against this sort of bug, > without the overhead of running Instruments which is often overkill for this > sort of problem, as well as causing performance issues that discourage its > use. "
Just a quick note: one problem with this is false positives; you don't necessarily control all the code that handles the object in question. You don't know if after handing an object to some other code (e.g. Foundation, the AppKit or some other third-party framework you've embedded) if that code did a retain/autorelease of its own, properly managing the lifetime for its purposes. At that point the object you're interested in is in the autorelease pool, but that's nothing to do with you (nor is it your problem). ...and you assert anyway. If Instruments is chowing too much memory for even a mid-size target process, then that's worth a bug. Not everyone is running 8GB or more on their development machines. :) Bill's weblog post is also a good resource. You can also write your own dtrace scripts to track messages to retain/release/autorelease to your own objects and that can help filter down the noise to only those objects of the class which are causing you problems. .chris -- Chris Parker iPhone Frameworks Apple Inc. _______________________________________________ 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
