Question regarding a memory leak (screen shot from Instruments included)

Question

Hi all,

I'm trying to weed my application out of memory leaks. The problem I'm facing is that Instruments is reporting leaks for objects which I have not explicitly allocated myself. Now, I do understand that these objects might be instantiated as a result of some other code I've written, but I cannot find my client-code anywhere in the stack. Here's a screen shot of the culprit set of objects which Instruments is reporting to be leaking: http://dl-client.getdropbox.com/u/57676/screenshots/leakss.png

Does anyone have any suggestions as to how I can go forward to figure out the true source of these leaks and remove them from the application?

Answer 1

I’ve seen some posts on this, seems a common frustration point.

I have an app that parses an XML file retrieved from a web service. It had a similar leak that was due to the URL cache.

I plugged the leak with the following code before calling init on XML parser:

[[NSURLCache sharedURLCache] setMemoryCapacity:0]; [[NSURLCache sharedURLCache] setDiskCapacity:0];

Answer 2

I cannot find my client-code anywhere in the stack.

That doesn't mean anything. Apple's code may run as a result of timers or user-initiated events (taps, etc.). Your code runs after Apple's code (e.g., Apple's mouseUp: calls your action method). Apple's code does more than just call your code; as such, it's not surprising to find a stack trace that contains only Apple methods.

So, that leak appears to be Apple's. You should file a bug in Radar.

This holds for the others, as well. Look at the stack trace; if it it shows no involvement by your code (i.e., Apple's code only), then you should file a bug. If your code allocated it, then it's (probably) your bug, so you should find it and fix it yourself.

Answer 3

To add another layer of certainty to this bug, I would consider running the LLVM/Clang Static Analyzer on your code. Taken from their site:

The LLVM/Clang static analyzer is a standalone tool that find bugs in C and Objective-C programs.

More specifically, it can check the amount of alloc, init, release calls in your code. It is quite useful.

For more information, Jeff LaMarche wrote a fantastic post on installing and using the Clang static analyzer, here.

Answer 4

Remember, your app may leak a few bytes here and there but if it's not affecting the functionality of the app itself, then it might not be a big issue. Obviously you don't want to leak memory if you can help it, but I haven't heard of Apple rejecting people's apps due to small memory leaks. Would love to be corrected on this if anyone HAS been rejected due to memory leaks.

Answer 5

These look very much like the leaks that appear in Simulator. If you run it off your iPhone, I bet you don't see the leaks anymore. Keep in mind Simulator doesn't mimic the iPhone's true environment. The definitive answer is to run off the iPhone. Simulator is good for testing but before you get to involved with what you see in simulator, make sure you also see it in the iPhone.

Answer 6

The other thing to check is does the memory leak increase with time? If it does not, then leaking 200 bytes will not be noticed. I guess the point is - there are only so many hours in the day and it is really likely that in a few hours of coding/debugging you could reduce your applications memory footprint by 10 or a 1000 times the few bytes that are shown as leaked in the screenshot you supplied.

Total memory footprint is what counts, and once only leaks if they cannot be easily tracked down are sometimes best left as is.

--Tom