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: Graham Cox <email@hidden>
- Date: Fri, 02 Jan 2015 12:20:04 +1100
> On 2 Jan 2015, at 10:52 am, David Duncan <email@hidden> wrote:
>
> The first thing to keep in mind is that unless otherwise qualified, all object references are owned - locals, ivars, array entries, etc. The places where this isn’t possible (such as structs) are flagged as compiler errors. The lifetime of ownership can typically be considered as “usage scoped” - that is, the object is owned up until its last reference, where by default you can think of it as released. There are exceptions to both of these rules, but they are generally minor and many likely line up with your expectations as well.
Thanks David, that does agree with the way I've been thinking about memory management with ARC, so I guess I'm probably not too far wrong. I don't think I'm running into any of those corner cases - everything is an NSObject, no CF stuff (in my code), and no structs, etc.
> Generally the answer would be to stop referencing objects when you don’t need them anymore, but Instruments’s Allocations tool would be the most useful thing to use to debug this - in particular retain/release tracking would likely be the most useful way to debug this issue. I would suspect the memory blocks at hand are being allocated for receiving the downloaded data and possibly wrapped as NSData objects.
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?
--Graham
_______________________________________________
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