Finding and Fixing Memory Leaks in iOS Apps

Finding & Fixing Memory Leaks
in iOS Apps
©2010 Streaming Colour Studios

Me: Owen Goss
5 years in console games industry
Streaming Colour Studios - Summer 2008
iPhone Games:
Dapple (Feb 2009)
Monkeys in Space (Nov 2009)
LandFormer (Jun 2010)
Chapter on iPhone Debugging

How many of you...

Already have an app in the App Store?

How many of you...

Are working on your ﬁrst app?

How many of you...

Are a Mac OS X developer?

How many of you...

Are a Mac OS X developer?
Have never touched Objective-C before?

Don’t worry...
www.streamingcolour.com/blog

This presentation and the example code I present will all be made available after the
conference on my blog.

The Plan, Man

What’s a Memory Leak
Retain, Release & Stuff
Common Leaks
Finding & Fixing Leaks

- To start, I’ll talk specifically about what a leak is
- I’ll give an overview of memory management in iOS
- I’ll go through some common ways to introduce leaks
- We’ll jump into Xcode with some sample code and actually find and fix a bunch of leaks.

What is a Memory Leak?

In order to talk about how memory leaks occur, how to fix them, and why they’re bad, we
first need to define what they are.

A memory leak is a piece of
allocated memory that
nothing points to.

There are two important things here: 1) we’re talking about heap memory, or memory that’s
allocated. Think: pointers. 2) We’re talking about a chunk of memory that’s “lost” on the
heap. Nothing references it anymore.

What’s a Leak?
Heap (memory)

// a = 0x0032ba80
MyClass* a = [[MyClass alloc] init];

// OR in C++
// MyClass* a = new MyClass();

// OR in C
// MyStruct* a = (MyStruct*)malloc(sizeof(MyStruct));

The previous slide stated that a leak involves a piece of allocated memory. This is how we
allocate memory in Obj-C (and examples in C++ and C). This takes a chunk of heap memory
of the size of our object and says “This memory is reserved”. The pointer, a, is just a number
that stores the address of the object in memory so we can ﬁnd it.

What’s a Leak?
0x0
...

// Memory leak!
a = nil;

But if you change the value of the pointer, to point to say, nil, then the chunk of memory we
allocated can no longer be found. However, no one told the OS that it could be freed, so it’s
still there with no way to be cleaned up. This is a leak.

The good news
No shared memory means you can’t leak
system-wide memory

You can’t leak OS-wide memory on the iPhone.

The good news
On exit ➟ app memory cleaned up

All memory you allocate during execution of your app is freed by the system when your app
shuts down. This includes any leaks you introduce.

The worst-case
You cause your own app to crash

In the worst-case, your leaks will cause you to run out of free memory and your app will
crash. Obviously this is a bad thing, but you can’t kill the OS with your leaks.

Retain, Release
& Stuff

Give a quick overview of memory management in iOS: retain & release
Stuff because we’ll talk about hidden retains, and some stuff like autorelease

iOS ➟ No Garbage Collection

For the Mac OS X/scripting language programmers in the room.

But...

Objects are reference counted

um... sort of...
if done right

NSObject has a property:
retainCount

Since all NS* and UI* classes in iOS are derived from NSObject, they also have retainCount.
Any classes you create that subclass NSObject have a retainCount.
But what does retainCount do?

if retainCount == 0
the object will be freed

The iOS memory manager uses the retainCount to determine when to free allocated memory.
If the retainCount becomes 0, the memory is freed.

retain/release

[objectA retain] //objectA.retainCount++

[objectA release] //objectA.retainCount--

At its most basic, calling retain on an object pointer increases the retainCount by 1. Calling
release decreases it by one. It gets more complicated, as we’ll see, but this is at the root of it
all. This is what you MUST understand about memory in iOS.

retain/release A.retainCount

B A 1

B A C 2

B A C 1

B A 0

Here we see some object A has been allocated in memory. Object B retains it with some
pointer. Then object C also retains it with its pointer. The retain count is 2 once both B & C
hold pointers to it. In order for A to get cleaned up, both B & C must release their pointers to
A.

If you retain, you must release

So remember: retain increases the retainCount by one, release decreases the retainCount by
1. When the retainCount is 0, the object is freed. If you take one thing away from this talk, it
is this. Think of it like parentheses that must always match.

“Hidden” retain/release

Here’s where things get a little more complicated. We saw before that calling retain on a
pointer to an NSObject increases the retainCount, but there are calls in Obj-C that increase
the retainCount “secretly”, or at least, quietly.

alloc

// objectA.retainCount = 1
MyClass* objectA = [[MyClass alloc] init];

...

// free the memory
[objectA release];

Let’s start at the beginning. The way you allocated memory for an object, in general, in
Objective-C is with the “alloc” method. This is like calling new() in C++ or malloc() in C, but
it’s reference counted. When you make an alloc call, it does an IMPLICIT retain on the pointer.
Objects that are alloc’ed must be released at some point.

retain Property Attribute

@interface MyClass : NSObject {
NSObject* objectA;
}

@property (nonatomic, retain) NSObject* objectA;

@end

Here we have a class called MyClass that has a property declaration for an NSObject instance
called objectA. Note the retain property attribute.

// @property (nonatomic, retain) NSObject* objectA;

@implementation MyClass

@synthesize objectA;
...

// objectA now points to objectB, and
// objectB.retainCount++
self.objectA = objectB;
// Equiv to: [self setObjectA:objectB];

...
@end

Note the use of the “self” keyword. This says that you want to use the property’s accessors to
set the value of objectA. This is the same as calling [self setObjectA:objectB]. This is NOT just
doing an assignment!



// It’s doing something like this...
- (void)setObjectA:(NSObject*)objectB {
[objectA release];
objectA = objectB;
[objectA retain];
}

When you do this, two things happen: 1) if objectA was holding a reference to some object,
that object gets an IMPLICIT release called on it. 2) an IMPLICIT retain is done on the new
object (objectB)!



// objectB.retainCount++

// NO RETAIN IS DONE!
objectA = objectB;

If you assign an object pointer to another WITHOUT the self keyword, the accessor of the
property is NOT used, and therefore NO retain is done! When you omit the self keyword, only
an assignment is done.



// objectA.retainCount--
self.objectA = nil;

// NO RELEASE IS DONE!
// Potential Memory Leak!
objectA = nil;

Similarly, using the self keyword to set an object to nil does an IMPLICIT release on the
object. But watch out, setting a pointer to nil without the self keyword COULD cause a
memory leak.

autorelease pools

Autorelease pools are collections of objects. They exist in a stack of pools. When you call the
autorelease method on an object, the object gets added to the top autorelease pool. Read the
Apple documentation on Autorelease pools for more information.

autorelease pools
on autorealese pool dealloc:

But an autorelease pool is an object itself. When it gets deallocated, it calls release on every
object inside it. iOS creates an autorelease pool every time through the run loop, and releases
it at the end (as well as at other points during execution, like touch events - see Apple docs).

autorelease pools

- (MyClass*) getNewMyClass {
// mc.retainCount = 1
MyClass* mc = [[MyClass alloc] init];

// When the current autorelease pool gets
// dealloc’ed, the retainCount will decrease
return [mc autorelease];
}

Here’s a good way to use autorelease in an iOS app: returning an allocated object. The calling
code can choose to retain the returned object if it wants to keep it long-term. But if it only
needs it right now, it can just use it and ignore it, and the autorelease pool will clean it up
later. Calling code doesn’t need to worry about it.

NSMutableArray (e.g.)

NSMutableArray* array = [NSMutableArray array];

[array addObject:objectA];

Lots of container class methods will retain your objects for you. This is almost always the
desired behaviour. Just remember that in order to decrease your retainCount, your object
either needs to be removed from the array, or the array needs to be destroyed. Read the
docs! Know what retains, what doesn’t.

NSMutableArray (e.g.)

NSMutableArray* array = [NSMutableArray array];

[array addObject:objectA];

Lesson: Read the documentation!

Lots of container class methods will retain your objects for you. This is almost always the
desired behaviour. Just remember that in order to decrease your retainCount, your object
either needs to be removed from the array, or the array needs to be destroyed. Read the
docs! Know what retains, what doesn’t.

alloc-init vs. other

// array1.retainCount = 1
// You must release to free it
NSArray* array1 = [[NSArray alloc] init];

// array2 is autoreleased
// You must retain to hold on to it
NSArray* array2 = [NSArray array];

Most of the built-in classes in iOS have two versions of initializers. One version will start with
init*, while the other starts with the class name (e.g. array, string, dictionary). The init
function always requires an alloc (and that alloc does the implicit retain). The other returns a
new object that is autoreleased.

Some Common Leaks

Let’s take a look at some common memory leaks and how to ﬁx them. Once we’ve gone
through these, we’ll jump into Xcode and the Leaks tool and do it for real.

Leak
// @property (nonatomic, retain) MyClass* objectA;

- (void)foo {
// retainCount = 2
self.objectA = [[MyClass alloc] init];
}

-(void)dealloc {
// retainCount = 1
[objectA release];
[super dealloc];
}

Note that the line in foo actually does 2 retains (self. and alloc). This object will leak objectA
when it gets dealloc’ed. When the object gets cleaned up, objectA still has a retainCount of 1,
but nothing will be pointing to it anymore: leak.

Leak Fixed

- (void)foo {
// retainCount = 1
MyClass* obj = [[MyClass alloc] init];
// retainCount = 2
self.objectA = obj;
// retainCount = 1
[obj release];
}

-(void)dealloc {
// retainCount = 0
[objectA release];
[super dealloc];
}
2 retains, 2 releases = leak ﬁxed.

Leak

- (void)foo {
self.objectA = obj;
[obj release];
// retainCount = 1
}

-(void)dealloc {
// retainCount = 1
[super dealloc];
}

So here we’ve done everything right...but oops! Forgot the release call in the dealloc method.
This is probably the most common leak you will encounter in your code, but luckily it’s the
easiest to ﬁx.

Leak Fixed

- (void)foo {
self.objectA = obj;
[obj release];
// retainCount = 1
}

-(void)dealloc {
// retainCount = 0
[objectA release];
[super dealloc];
}

2 retains, 2 releases = leak ﬁxed.

Build & Analyze
Try it, it might work for you.*

* or wait for Xcode 4

Build & Analyze is a build option in Xcode that runs the CLANG static analyzer. It can
sometimes pick up memory leaks in your code at compile time! I’ve never had much luck
getting it to work properly in Xcode 3.x, but give it a try in Xcode 4.

Leaks Instrument
Leaks will show you the allocation that leaks. It’s
up to you to ﬁgure out why it wasn’t released.

This is what you need to understand about the Leaks tool. It’s an amazing tool, but it can’t
do everything for you. You still need to understand your own code and how memory
management works.

Xcode Time!
http://streamingcolour.com/presentations/
memLeakExampleProject.zip

Now that we’ve got all that under our belts, I’m going to jump into Xcode, boot up the Leaks
Instrument and show you how to ﬁnd these things for real. Download the project here:
http://streamingcolour.com/presentations/memLeakExampleProject.zip

Fin.
Questions.
twitter: @OwenGoss
email: owen.goss@streamingcolour.com
web: www.streamingcolour.com

Finding and Fixing Memory Leaks in iOS Apps

More Related Content

Viewers also liked

Recently uploaded

Finding and Fixing Memory Leaks in iOS Apps