Finding and Fixing Memory Leaks in iOS Apps

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...

How many of you... Already have an app in the App Store?

How many of you... Already have an app in the App Store? Are working on your ﬁrst app?

How many of you... Already have an app in the App Store? Are working on your ﬁrst app? Are a Mac OS X developer?

How many of you... Already have an app in the App Store? Are working on your ﬁrst app? 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]; ... // objectA.retainCount = 0 // 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.

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!

self.objectA = objectB; // @property (nonatomic, retain) NSObject* objectA; // 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)!

retain Property Attribute // @property (nonatomic, retain) NSObject* objectA; // objectB.retainCount++ self.objectA = objectB; // 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.

retain Property Attribute // @property (nonatomic, retain) NSObject* objectA; // 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]; // objectA.retainCount = 1 MyClass* objectA = [[MyClass alloc] init]; // objectA.retainCount = 2 [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]; // objectA.retainCount = 1 MyClass* objectA = [[MyClass alloc] init]; // objectA.retainCount = 2 [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.

All Clear? Moving on...

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 // @property (nonatomic, retain) MyClass* objectA; - (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 // @property (nonatomic, retain) MyClass* objectA; - (void)foo { MyClass* obj = [[MyClass alloc] init]; 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 // @property (nonatomic, retain) MyClass* objectA; - (void)foo { MyClass* obj = [[MyClass alloc] init]; 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

http://www.streamingcolour.com	1413
http://210.183.172.162	6
http://translate.googleusercontent.com	3
http://a0.twimg.com	3
http://www.techgig.com	1
http://cache.baidu.com	1
http://us-w1.rockmelt.com	1

Finding and Fixing Memory Leaks in iOS Apps

by Owen Goss on Sep 21, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 1,428

Statistics

Finding and Fixing Memory Leaks in iOS Apps — Presentation Transcript