A while back I had a similar sounding issue in an iOS project I was working on. The memory usage kept growing, although I could find no obvious culprits in my code after hours of exploration. My solution probably doesn’t pertain to you, but I thought I’d pass it along just in case it’s something you might have overlooked.
I showed my project to another more experienced developer seeking help. He agreed with my assessment that there weren’t any apparent major problems with my code. But he discovered that I had left Zombies detection turned on in the project scheme settings (left on from exploring another issue some time back). So of course Instruments was showing me the memory that Zombies was holding onto. Turning off Zombies detection gave me a very steady memory usage pattern. > On Jan 1, 2015, at 5:20 PM, Graham Cox <graham....@bigpond.com> wrote: > > 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? _______________________________________________ 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
