Hi Guys, Since we are on the topic I noticed something interesting in my code. My development environment is 10.9.1, and when ever I run ³leaks² command to check for memory leaks I get none. It seems pretty clean. 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 - break on objc_autotreleaseNoPool() to debug. This is bizarre as I would have expected to see this problem on 10.9 as well. Can someone explain what is going on here?
Regards, Varun On 23/04/2014 9:18 am, "Quincey Morris" <quinceymor...@rivergatesoftware.com> wrote: >On Apr 22, 2014, at 15:18 , Dave <d...@looktowindward.com> wrote: > >> I assumed that ARC would release myImage on each interation of the >>loop, however, this seems not to be the case > >The ŒmyImage¹ variable gives up *ownership* of the previous image object >when you create a new one in the loop, but whether that leads to a >deallocation of the object is an implementation detail. If it¹s >autoreleased anywhere in its [short] lifetime, the image object will >linger in the autorelease pool until the pool is drained, as Keary said. > >If you want to avoid autoreleases, you should ensure that the image is >returned from the download method with +1 ownership semantics. As far as >that method is concerned, you can do this by changing its name to start >with ŒnewŠ¹, or decorate its declaration with >Œ__attribute__((ns_returns_retained))¹. You would, of course, have to >ensure that the download method and the methods it calls don¹t do >anything else that¹s likely to retain/autorelease the image. > >This sort of thing is a bit messy because it relies on presumed (but >partially documented) knowledge of the ARC implementation. It¹s more >robust and straightforward to do what Keary says. However, if you really >wanted to avoid autoreleases completely, there are ARC strategies that >can help. > >_______________________________________________ > >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/varun.chandramohan%40won >tok.com > >This email sent to varun.chandramo...@wontok.com _______________________________________________ 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
