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: Tue, 13 Jan 2015 14:20:51 +1100
Thanks - sorry I missed it in the first mail for some reason.
An interesting thread. This remark from Quinn stood out for me:
"If you stop issuing new requests, NSURL{Session,Connection} quickly recovers this memory to the point where, at the end of a cycle like this, the memory use (as shown by Allocations) is pretty much the same as when you started (a generational analysis shows just a few KiB of growth). So the problem here is not a leak, or even abandoned memory, but rather a delay in recovering memory."
This could be what I'm seeing as well, since as a stream is downloaded, each chunk is pretty much requested as soon as the previous one completes, and is triggered by that completion (though I am rescheduling it on the main thread, which in turn adds it to the session's operation queue).
What's not clear is what is needed to cause the memory recovery to occur. I presume that invalidating the session will do that, but that isn't appropriate for in-between chunks.
I'll look into this angle and see if I can prove anything. If so, I'll file a radar and hope it comes back as dupe, fix imminent :) (though I won't be holding my breath)
--Graham
> On 13 Jan 2015, at 2:01 pm, Roland King <email@hidden> wrote:
>
> https://devforums.apple.com/message/1056669#1056669
>
> No that one from the same mail.
>
>
>
> On 13 Jan 2015, at 10:51, Graham Cox <email@hidden> wrote:
>
>>
>>> On 13 Jan 2015, at 12:21 pm, Roland King <email@hidden> wrote:
>>>
>>> Did you read the devforums thread I pointed you at a couple of weeks ago?
>>
>>
>> Umm, not sure Roland. I read the blog post by bbum about using Allocations, which is the one you linked in this thread. Did you mean something else? Forgive me, I can't locate the link if so.
>>
>> If you're referring to bbum's post, I read that. I'm assuming that "heapshot" is now labelled "mark generations" but otherwise is the same thing. The problem with this in my case is that a "generation" is a new URL download and that's fired off automatically by either the previous one completing or a timer that's set to a variable time based on the "target time" of the playlist entry. There's no clear means for me to hit "mark generation" at exactly the right time. That might not matter all that much in that the process is continuous, so as long as I'm downloading a stream at a fairly steady rate, and hit the button at regular intervals, there should be a reasonable similarity between runs.
>>
>> Doing that, I get inconclusive results. Most of the memory that is left is like this:
>>
>> Snapshot Timestamp Growth # Persistent
>> Generation B 01:32.780.375 2.09 MB 38
>> VM: Performance tool data 2.08 MB 4
>> 0x116816000 01:13.421.801 532.00 KB
>> 0x1162ed000 01:32.145.259 532.00 KB
>> 0x116140000 01:23.051.011 532.00 KB
>> 0x1161e5000 01:02.847.030 532.00 KB
>>
>>
>> Which suggests it's memory allocated by Allocations itself.
>>
>> But where I'm checking this over longer time periods isn't in Instruments at all, but in Xcode's memory viewer. Unfortunately that doesn't give me a breakdown, just an overall usage.
>>
>> --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