Finding Leaks in Xcode

Xcode has a Run with Performance Tool menu choice. If you drill into that, one of the options is "Leaks". As you might expect, this checks your application for memory leaks.

Memory leaks in iPhone/iPad apps are important because these devices have limited amounts of RAM and (at least as I write this) don't page app code in and out. This means that if you allocate memory, that memory is unavailable to anything else (including your app itself) until you specifically let go of it.

Because Objective C manages memory by reference counting> rather than garbage collection, and because the rules for that are a bit confusing to newbies, it's painfully easy to screw up and neglect to release memory back to general use.

That's where the Leaks Performance Tool can be helpful. Unfortunately, for the person who probably needs it most (those of us just learning our way around the SDK), the Leaks Performance Tool itself is maddeningly confusing and ill-documented.

If you create a perfectly valid, leak free application, the Leaks Tool will tell you that it leaks. Did you catch that? I better stress it: If you create a perfectly valid, leak free application, the Leaks Tool will tell you that it leaks.

I don't know why. I don't know if these leaks are from sloppiness in the libraries your code uses, if the leaks are simply unavoidable in that code or if the Leaks Tool misunderstands something and misreports it. It doesn't matter: it WILL report leaks.

Perhaps even more confusing is that what it calls a "leak" isn't exactly what you or I might call a leak. I'd say that if your program is losing a bit of ram on each cycle, it's leaking. However, if your program allocates a 5,000 byte buffer and neglects to release it in a subroutine that is only called once, I don't call that a leak. Sloppy, sure, but your program can run from now to the next millennia and never run out of memory, so it's not "leaking" in my book. You might convince me to agree that it leaked once when that subroutine ran and that's exactly how the Leaks Tool perceives things: a leak is a leak even if it never repeats.

So, here we are. Every allocation not properly freed is a leak and the Leaks Tool will see leaks that you didn't cause. Great: how do you use it to find leaks you HAVE created?

We'll start with a simple, non-leaking iPhone or iPad app. I told Xcode I wanted a new project, chose "View Based" and called it "UsingLeaks". In Interface Builder I added a button and a Webview box,. I referenced them in my UsingLeaksViewController.h file:

#import <UIKit/UIKit.h>

@interface UsingLeaksViewController : UIViewController {
	UIWebView *showsomething;


@property (nonatomic, retain) IBOutlet UIWebView *showsomething;

- (IBAction) buttonPressed: (id) sender;


and in UsingLeaksViewController.m:

int num=0;

#import "UsingLeaksViewController.h"

@implementation UsingLeaksViewController

@synthesize showsomething;

// Don't forget to connect your button and your webview in IB!

- (IBAction) buttonPressed: (id) sender {
	NSString *message= [[NSString alloc] initWithFormat:\
@"<h2>You must have clicked me  %d times!</h2>",num];
	[showsomething loadHTMLString:message baseURL:[NSURL URLWithString:@"/"]];
	[message release];


Of course I used Interface Builder to connect the gozintas and gozoutas after adding that code. Don't forget to SAVE the Interface Builder changes!

I did a Build and Run to be sure I hadn't mistyped anything and then ran that through the Leaks Tool. It showed leaks even before clicking on the button to fill the Webview: (click on "Leaks" or its graph to get that window).

No Real Leaks

Those are the "one time" type of leak. You can click on the button all day long and they never get any worse.

So how do I know they aren't mine (aside from the obvious fact that I haven't done anything that should cause a leak)?

To show you that, we need to deliberately create a leak and see what THAT looks like. That's easy to do - I'll just comment out that "[message release];", build the app and see what the Leak Tool reports now (you need to click on the button to create a leak - each button click leaks more).

By the way, you really don't need this Leak Tool to find a leak like this. If you run "Build and Analyze", your neglect gets spotted instantly:

Build and Analyze

It may be hard to see in this reduced image, but the lower right hand corner says "Potential leak of an object allocated on line 21 and stored into 'message'". Ayup. I agree, and we plainly don't need the Leak Tool. Actually, so far I haven't found ANY condition where I needed it, but I'll assume that there must be some complicated situation that Build/Analyze won't notice, so we'll proceed anyway.

So, we run it through the tool. What do we get? A few more things shown in the Leaks section. Back to the original question: how do we know which are from our code?

The answer is to turn on "Extended Detail View". That's Apple E or choose it under the View menu choice. Click on a leak and the Extended Detail View fills up with a stack trace. Here's a corner of it:

Our Leaks

See where the arrow points? What does it say there? It says "Using LeaksViewController Button Press" and under that it even tells us what line number was responsible for the leak I clicked.


Click on any other line in the Leaks section and you'll see names of libraries, but not the name of your project. THAT is how we know which leaks are ours.

You can double-click on the leak line and it will open the editor at the referenced line - that's fine, but I don't have a clue as to how you get back to the Leaks view from there!

Though as I noted above, Build and Analyze would have told us that for far less effort and confusion. There's much more to Build and Analyze than I showed here; (link dead, sorry) Apple's Static Analysis in Xcode goes into more detail.

Build and Analyze is new with Xcode 32.2 - it may be that this makes the "Run with Performnce Tool Leaks" superflous. So far, that's been my experience.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Finding Leaks in Xcode with run with performnce tool leaks


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Thu Jun 10 08:08:39 2010: 8689   anonymous


when i intentionally put a memory leak and select build and analyze... it doesn't give me any potential memory leak as analyzer result

if i write

NSMutableArray *tempArray = [[NSMutableArray alloc] initWithCapacity:6];

NSMutableArray *tempArrayfinal = [[NSMutableArray alloc] initWithCapacity:12];

and doesn't release it... it is not giving me any potential leak but if i write

NSString *leakyString = [[NSString alloc] initWithString:@"Leaky String "];


here it gives me potential leak as analyzer result...why it is not giving potential leak in NSMutableArray and why it gives potential leak in NSString ?... how can i rely on Build and analyze for memory leak...

I've run the app with Leak tool and it is showing me leak in tempArray and tempArrayfinal

please help...

Thu Jun 10 11:19:54 2010: 8691   TonyLawrence


No point in asking me. I'm very new to all this.

Fri Jul 2 20:36:38 2010: 8776   abes


Get back to the leaks view at the very bottom of the window. You will see the standard buttons ( a window, three lines on top of one another with each indenting a little more, four boxes connected to their adjacent neighbor by a line). Next to that, you will see some words, separated by arrows/less than signs ( > ). Each one of those words is a tab. It confused me for a solid 5 minutes, too, hope this helped you though.

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

An algorithm must be seen to be believed. (Donald Knuth)

When someone says: "I want a programming language in which I need only say what I wish done", give him a lollipop. (Alan J. Perlis)

This post tagged: