Instruments Tutorial for iOS: How To Debug Memory Leaks

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!