NSData memory hog problem

Question

Created Sep ’17

Replies 1

Boosts 0

Participants 2

I had two rare customer report about one of my apps that after long time of running, the app eats up about 2GB memory. I'm quite puzzled in that I do not observe this problem for the past 2 years and I have only 2 customer reports on this problem.

The only place that I can think of that eats up memory gradually is one of the method of NSURLConnectionDataDelegate:

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
    [_data appendData:data];
}

The data then is stored in an NSMutableDictionary which is then added to a list. After verything is done, the dictionary is removed off list. That should work without problem and I cannot think of any problem that can cause memory leaks.

Any suggestions will be appreciated.

Boost

Answer 1

QuinceyMorris OP

Sep ’17

Eats up 2GB according to what measurement? You need to be certain this isn't (say) harmless consumption of virtual address space with no associated leakage of usable memory. However, assuming there's really a problem…

The "didReceiveData" method seems like the least likely cause of the problem, since this seems like it would be a frequently used path through your code. If there was some gross bug, you'd expect it to fail more often. In the absence of other information, I'd guess it's more likely the problem exists in your error handling, when data is not received, so execution does not go through this delegate method. Is there some sequence of errors that trip up your error recovery so that something is not released (possibly the "_data" object, or the mutable dictionary, but equally possibly some entirely different object)?

If the problem is repeatable for these 2 customers, you can try adding code (maybe triggered by a secret menu item or button) that attempts to discover what the leaked memory consists of and logs helpful information.

If the problem is not easily repeatable, there's really no good strategy for solving this, other than reading and re-reading your code very carefully. Or, perhaps, you could experiment with artificial error conditions that might trigger this behavior. This sort of thing is not at all easy.

0