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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
