Re: Memory Leaks and ARC
Re: Memory Leaks and ARC
- Subject: Re: Memory Leaks and ARC
- From: Varun Chandramohan <email@hidden>
- Date: Wed, 23 Apr 2014 01:38:11 +0000
- Thread-topic: Memory Leaks and ARC
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"
<email@hidden> wrote:
>On Apr 22, 2014, at 15:18 , Dave <email@hidden> 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 (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:
>tok.com
>
>This email sent to email@hidden
_______________________________________________
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