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 12:00:25 +1100
I'm still having an issue with this - I think.
I've exhaustively hunted down every leak and memory allocation in my app - luckily it's a fairly small one, though one that can create many threads - and have eliminated everything I have control over*
My heap space is still growing over time. I'm having a LOT of trouble understanding how to use Allocations Instrument effectively - I just can't really understand what it's trying to tell me. I have read the documentation for Allocations but it's not really much help, because it's hard for me to 'mark generations' when a 'generation' is something that happens as a result of external factors, not a user-interface action.
I've satisfied myself that possible issues to do with blocks causing potential retain cycles are definitely not the issue, nor is fumbling my way using ARC for the first time**.
What I'm left with is either a genuine memory leak that occurs inside the CFNetwork framework, or an apparent memory leak that isn't one really that I can safely ignore. I'm just not sure which.
To recap, what my app does is to record chunks of video data to a file using NSURLSession and NSURLSessionDataTask. These chunks are obtained by parsing a .m3u8 playlist file. Each 'chunk' is a unique URL which is generated by the server and persists for a fairly short time. By concatenating the data returned by each fetch of these URLs, a complete capture of a live stream is achieved. Overall, this process works great with the nagging problem of growing memory usage. This growth appears to be somewhat related (but not exactly correlated with) the amount of data downloaded and recorded. For example, at first the "leak" is somewhat larger than what I record, but over time it becomes quite a bit smaller. However if I record nothing, there is no leak. What concerns me is that the "leak" can get large - after a day or so of running, it's getting up to 3GB for example.
In my NSURLSessionConfiguration, I have turned off the URLCache (set it to nil) - there's no purpose to caching data for the chunks because they are only ever accessed once. Similarly I've disabled cookies. What I should be looking at is a straightforward uncached download of a URL, write that data to disk and move on. Here's my config setup:
self.configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
NSDictionary* additionalHeaders = @{@"User-Agent":XViPadUserAgentString};
self.configuration.HTTPAdditionalHeaders = additionalHeaders;
self.configuration.HTTPCookieAcceptPolicy = NSHTTPCookieAcceptPolicyNever;
self.configuration.HTTPCookieStorage = nil;
self.configuration.URLCache = nil;
self.session = [NSURLSession sessionWithConfiguration:self.configuration];
So my question is, has anyone used these classes and seen something similar occurring? Is it just "one of those things", or am I still doing something wrong? At this point I'm just not sure what else I can do. Is some of that URL download being cached anyway, despite me telling it not to bother? Is it just cache growth I'm seeing and that's being managed elsewhere? Maybe 3GB after a day or two is acceptable?
*One of the things I tried in desperation is to turn off ARC and go back to manual memory management. Fact is, I'm just more comfortable with MM at the moment. I'm not claiming ARC is bad or anything like that, but in trying to hunt down the issue, I wanted to have as familiar territory as possible. In fact the manual memory management did allow me to discover a few other leaks where I'd obviously not told ARC the right thing (e.g. something was not being released because it created a timer, and the timer was invalidated in -dealloc, which of course doesn't work, even in MM land), but not related to this leak problem, which persists.
** See above - there is no ARC now.
> On 2 Jan 2015, at 2:45 pm, Graham Cox <email@hidden> wrote:
> What appears to be amassing are 132KB malloc'd blocks (by the hundreds). These are created by HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, unsigned long), down in CFNetwork. The stack trace is:
>
> 0 libsystem_malloc.dylib malloc_zone_malloc
> 1 libsystem_malloc.dylib malloc
> 2 CFNetwork HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, unsigned long)
> 3 CFNetwork CFNetworkReadStream::_readStreamClientCallBackCallBack(__CFReadStream*, unsigned long, void*)
> 4 CoreFoundation _signalEventSync
> 5 CoreFoundation _cfstream_shared_signalEventSync
> 6 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
> 7 CoreFoundation __CFRunLoopDoSources0
> 8 CoreFoundation __CFRunLoopRun
> 9 CoreFoundation CFRunLoopRunSpecific
> 10 CFNetwork +[NSURLConnection(Loader) _resourceLoadLoop:]
> 11 Foundation __NSThread__main__
> 12 libsystem_pthread.dylib _pthread_body
> 13 libsystem_pthread.dylib _pthread_start
> 14 libsystem_pthread.dylib thread_start
_______________________________________________
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