Did you read the devforums thread I pointed you at a couple of weeks ago? I
noted it was iOS not OSX however my general belief is as time goes by, more and
more code is common to the platforms so if there’s a bug in iOS at 8.x (and
there is) it may also exist on OSX at some recent version. On that thread
someone was doing what you’re doing, scheduling new NSURL requests at the
completion of the previous one and they were getting constant memory growth.
I’d also suggest at this point after tearing things apart for quite a while and
putting them back together again, you might be best served asking DTS for help.
If you’re lucky Quinn will pick up the ticket, but even if he doesn’t someone
should actually be able to help you make sense of your allocations traces and
tell you if there is a current, open bug in NSURLSession.
> On 13 Jan 2015, at 09:00, Graham Cox <graham....@bigpond.com> wrote:
>
> 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 <graham....@bigpond.com> 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 (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
