Re: Debugging memory leak in NSURLSession with ARC
Re: Debugging memory leak in NSURLSession with ARC
- Subject: Re: Debugging memory leak in NSURLSession with ARC
- From: Cosmo <email@hidden>
- Date: Thu, 01 Jan 2015 18:02:20 -0800
A while back I had a similar sounding issue in an iOS project I was working on. The memory usage kept growing, although I could find no obvious culprits in my code after hours of exploration. My solution probably doesn’t pertain to you, but I thought I’d pass it along just in case it’s something you might have overlooked.
I showed my project to another more experienced developer seeking help. He agreed with my assessment that there weren’t any apparent major problems with my code. But he discovered that I had left Zombies detection turned on in the project scheme settings (left on from exploring another issue some time back). So of course Instruments was showing me the memory that Zombies was holding onto. Turning off Zombies detection gave me a very steady memory usage pattern.
> On Jan 1, 2015, at 5:20 PM, Graham Cox <email@hidden> wrote:
>
> I'm using Allocations, but I'm finding the volume of data a bit overwhelming.
>
> As an aside, Leaks shows nothing at all. Does that mean I'm not actually leaking anything?
>
> What I'm seeing sort of agrees with expectations - the memory usage graph has a broadly "sawtooth" waveform as each download task is created, builds up, is processed and released. However the underlying memory usage continues to climb, with the sawtooth on top. Breaking down the allocations shows that the 132KB bufers are the vast majority of the allocations, but maybe my interpretation that they're not being freed is wrong - they are listed but maybe that doesn't mean they're not being freed? I don't know - there's the problem, I'm not terribly clear on how to interpret the data.
>
> Regarding the NSData I'm passed in my NSURLSessionDataTask completion block (which are the biggest blocks I handle), I write that data to an open file handle and that's the last time I reference it. I don't own that NSData anyway, so even under classic MM I wouldn't do anything special about it. I guess NSFileHandle could be retaining that NSData. I leave that file handle open continually as long as a download stream is available, so it might be that it's not releasing NSData blocks passed to -writeData: until it is closed. That could explain what I'm seeing, though thinking about *why* NSFileHandle would retain that data is not so obvious - why indeed? Wouldn't it just copy that data to the file and release it?
_______________________________________________
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