On Apr 22, 2014, at 6:49 PM, Jens Alfke <j...@mooseyard.com> wrote: > On Apr 22, 2014, at 6:38 PM, Varun Chandramohan > <varun.chandramo...@wontok.com> wrote: >> However when I >> run the same code in older OS 10.7.x and run leaks there I noticed big >> dump of leaks and my daemon (runs without a UI) has numerous _NSCFString >> autoreleased with no pool in place - just leaking - > > If you’re creating NSThreads, make sure the main/top-level method of each > thread has an autorelease pool. I seem to recall some change in functionality > there in recent OS versions. > >> break on objc_autotreleaseNoPool() to debug > > …but instead of listening to me speculate, you could set a breakpoint on that > function and find out exactly where the leak is happening.
In recent OS versions, calls to +load methods are automatically wrapped in autorelease pools. Older OS versions did not do this. This is one possible cause of "autoreleased with no pool in place" on older OS versions. In this case there is no leaked or abandoned memory on recent OS versions, but there will be leaks on older OS versions. In recent OS versions, the runtime automatically creates an autorelease pool on a thread if you call -autorelease without one in place. This pool will live as long as the thread does. This is another possible cause of "autoreleased with no pool in place" on older OS versions. In this case there may be abandoned memory on recent OS versions, if your thread is long-lived and lots of objects fall into this pool. You can run with OBJC_DEBUG_MISSING_POOLS=YES to get "autorelease with no pool in place" messages here that are similar to the ones you get on older OS versions. (History: some OS version accidentally introduced the create-new-pool-automatically behavior in some cases. We couldn't undo that without breaking some apps that shipped in the meantime, so instead we formalized it and added the OBJC_DEBUG_MISSING_POOLS=YES log. Somewhere around here I have a feature request for Instruments detection of "old" autorelease pools that are hanging on to objects that should be dead.) -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
