Instruments Tutorial for iOS: How To Debug Memory Leaks

Leaks and Plumbers

Unfortunately, you can’t rely on Build\Build and Analyze to catch everything. There’s one other great automated tool to help you check your app for leaks – the Leaks Instrument.

Let’s try it out. Go to Run\Run with Performance Tool\Leaks, and select a few rows in the table view. Also scroll up and down the table view from the top of the table to the bottom of the table. After bait of experimentation, you should start seeing some leaks popping up in the Leaks tab, which show up as blue bars.

Click the stop button, then go to the toolbar in the middle and click it to change from “Leaked Blocks” to “Call Tree”. In the panel in the lower left, click “Invert Call Tree”, and “Hide System Libraries”. You’ll see that it found two different methods in the code with memory leaks, as you can see below:

If you double click a function name, it will take you directly to the line of code that creates the object that was leaked. This should give you a really good hint where the problem lies, and if you examine the code and think about it a bit, you should be able to figure out what the problem is and fix it.

So why not take a look at the code and see if you can figure out what the problem is and fix it? Once you’ve made a fix, you can run Leaks again and verify that the leak no longer occurs. Come back here once you’ve finished, or gotten stuck!

…
…waiting…
…
…waiitng…
…
…waiting…
…

Tomato-San is angry!

Tomato-San is angry!

What?! Are you still reading here?! You can do it – go ahead and try! :]

The Solution

tableView:didSelectRowAtIndexPath

Leaks tells us that the string created and stored into sushiString is leaked. So let’s think through why this is, step by step:

1. When sushiString is created, it’s created with stringWithFormat. This returns an object with a retain count of 1, and a pending autorelease.
2. In the last line in the method, you call retain on the sushiString (bumping the retain count up to 2) and store it into _lastSushiSelected.
3. Later on, the autorelease takes effect, decrementing the retain count to 1.
4. Next time the tableView:didSelectRowAtIndexPath method is called, you override the _lastSushiSelected variable with a pointer to a new string – without releasing the old one! So that old string still has a retain count of 1, and is never released.

One solution to this is to add the following line before setting lastSushiSelected to the sushiString:

[_lastSushiSelected release];

tableView:cellForRowAtIndexPath

Just like in the previous method, a string that’s created and stored into a variable named sushiString is leaked. Here’s what’s going on:

1. A new string is created with alloc/init.
2. This returns an object with a reference count of 1.
3. However, this reference count is never decremented, so there’s a memory leak!

This could be solved in one of three ways:

1. Call release on sushiString after setting the textLabel to the string.
2. Call autorelease on sushiString after creating it with alloc/init.
3. Instead of using alloc/init, use stringWithFormat, which returns a string already marked as autorelease.

Plumb the Leaks!

Fix the above two problems, compile and run Leaks again, and verify that you no longer have any leaks in the app!

Where To Go From Here?

Here is a sample project with the updated app, with no leaks or crashes.

At this point, you should have some good hands-on experience with how to find memory leaks in your app using NSZombieEnabled, Build and Analyze, and the Leaks Instrument. You should be able to apply these techniques to your projects to help find and resolve memory leaks!

Next check out the third article in this series, where I cover how to check your apps for memory leaks or memory-related mistakes, via using Instruments and other helpers.

If you have any other advice or tips to developers for good techniques to find memory leaks in your apps, please add your thoughts in the comments below!