September 9th, 2009

Static Analysis in XCode 3.2

iPad, iPhone, Mac, by BigSprocket.

One of the best new features in XCode 3.2 is the static analyzer. If you build using the menu item “Build and Analyze” (or Shift-⌘-A), XCode will analyze your code for potential memory leaks and bring them to your attention. Let’s take a look at how cool this is.Here’s some leaky code:

int main(int argc, char *argv[]) {
	NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

	NSArray *foo = [[NSArray alloc] initWithObjects:@"bar", @"baz", nil];
	NSLog(@"foo contains %@", foo);

	[pool release];
	return 0;
}

Type that in and Build without the static analyzer, and it will report no problems. It’s valid code, so it compiles. BUT, there’s a memory leak in it … Line 4 allocates an NSArray, but it is never released.

Quick note: I talked about memory management earlier. If you didn’t read that post, please do. In a nutshell, what you need to know is this: If you create an instance of an object via alloc, new (which usually calls alloc behind the scenes) or copy, it is your job to release the object when you’re done with it. If you get the object some other way (maybe through some other convenience method), the creator should have autoreleased it, so you don’t have to. That is, unless you retained it. If do retain it, which you need to do if you want it to be around from method call to method call, you must release it when you no longer need it.

So… again, in the code above, we’re creating an NSArray via alloc, so we’re supposed to release it when we’re done, otherwise it’s a possible leak. (In this case, where the app is immediately ending, it’s no big deal, but go with me on this one … pretend that code exists somewhere within a larger long-running app.)

Now use the “Build and Analyze” option from the Build menu. Your Build Results pane will look something like this:

BuildResults.png

We also got a little flag in the code editor pane:

FlaggedLeak.png

Here’s the super cool part. Click the flag.

LeakDetail.png

Whoa. Color glossy pictures with circles and arrows and a paragraph on the back of each one. (Arlo Guthrie had a garbage problem, and so do we.)

That spiffy arrow traces the path the analyzer took in detecting the leak. The real magic is in the messages. Where we allocate the array, XCode tells us “Method returns an Objective-C object with a +1 retain count (owning reference)”, which means we own this object … we made it, we must get rid of it. On the line releasing the pool, we’re told “Object allocated on line 16 and stored in ‘foo’ is no longer referenced after this point and has a retain count of +1 (object leaked)”. Well, you can’t get more specific than that … we made “foo”, we should have released it, but since we didn’t, it leaked.

It won’t take much to retrain my fingers to press shift-⌘-A to build instead of ⌘-B or ⌘-Y, and with this awesome tool helping to prevent leaks, it’ll be well worth it.

Back Top

Responses to “Static Analysis in XCode 3.2”

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

You must be logged in to post a comment.