DEV » OS Development

Finding hidden memory leak with Instruments

dev — Tue, 23 Mar 2010 07:20:52 +0000

Using the 1 Mb NSDateFormatter memory leak as a case-study, this tutorial shows how to locate and isolate unexpected memory allocation using Instruments. Technically, this 1 Mb loss is arguably not a leak, since the data is cached, and is still actively referenced by the system. Yet…

Instruments has built-in tools to isolate true leaks (lost blocks) but can also be used to locate memory loss. While this session references iPhone OS 3.1.3, it can be generalized: only the example is specific, not the concept.

…as an engineer, I tend to differ: if every time I invoked a library API, I’d loose roughly 1 megabyte of RAM, I’d soon be running out of memory. I will also argue that, since this memory “cache” is neither documented nor explicitly reported it is, for all purposes, a leak(*).

(*) A leak is a lost block. But not all lost blocks qualify as leaks. This article focuses on the ones that don’t. Just like leaks, these lost blocks are consuming memory space. That space is generally not reclaimed until the host application quits.

1. Launch Instruments

From XCode, launch your application using “Object Allocations”
Run > Start with Performance Tool > Object Allocations" src="http://thegothicparty.com/dev/wp-content/uploads/2010/03/ss01.png" alt="" width="512" height="324" />For this tutorial, we are not using Leaks Instrument Template. While Leaks is very effective against true leaks, it is oblivious to retained but forgotten objects, over-retained objects, or poor API implementation.

2. Run your application

In this example, only 32 seconds (about 0.54 minutes in Instruments notation) were needed to expose the unexpected memory usage.

It is a good idea to be generous in early scoping of memory usage, since it will fluctuate. For the purpose of this tutorial, this preliminary analysis phase has been skipped entirely.

3. Stop the Application execution

It has been established during other sessions that the particular memory consumption we are studying does not change during the lifetime of this application. Stopping it after 34 seconds.

Instruments can start/stop/save/restore sessions, which makes it invaluable to compare the program behavior before/after alterations.

4. Objects Created and Still Living

Focus on the objects that have been allocated, but not de-allocated.

Obviously, objects created but no longer living have been de-allocated, and are not of particular interest while searching for leaks.

5. Observe the Object Allocation Graph

Looking at the graph, it is easy to spot sudden memory allocation. For increased granularity, reduce the “Inspection Range”.

The Inspection Range will reduce the number of items present in the Diagram View below.

6. Set the View mode to Diagram View

7. Navigate the Diagram View

This is a very handy feature of Instruments. By sliding or dragging the time line cursor, the Diagram View selection will scroll accordingly. By bringing the triangular cursor precisely over the edge of the sharp raise of memory usage around the 0.54 min (32.5 seconds) area, one discovers pages and pages of a repeated call to -[NSDateFormatter getObjectValue:forString:range:error:]

8. Focus on the Diagram View

Observing the Diagram View, sorted either by “Responsible Caller” or by “Creation Time”, one can see the repeated invocation to the same NSDateFormatter method.

9. Call Stack

Turn on the call stack view (Extended Detail View)

10. Final analysis

By selecting a single line in the Diagram View, and inspecting the corresponding call stack in the Extended Detail View, one can focus on a single invocation and, hopefully, isolate the code responsible for the memory allocation. A double-click will jump to the source code, if available.

For example, +[Manager dateFromString] is the method responsible for invoking the suspicious NSDateFormatter -dateFromString selector.

Two facts will attract our attention:

There are pages upon pages of NSDateFormatter invocations, all grouped together when sorted by Responsible Caller.
When sorted by Creation Time, about 8000 invocations to NSDateFormatter take place within the same 100 ms.

When looked at closely, this study lead to a decision to not use NSDateFormatter time zones, which turned out to be the culprit.

11. Related links

Bookmark this on Delicious

NSDateFormatter memory leak

dev — Thu, 11 Mar 2010 20:15:08 +0000

This is a follow-up to a post on stackoverflow.com, where it appears that 1 MB is lost after invoking NSFormatter -dateFromString.

I ran into the same situation, with very similar leak sizes to the ones reported on that article. Instruments shows that 868 Kb (889520 bytes to be exact) are allocated by Cocoa on iPhone OS (verified from 2.x to 3.x up to 3.1.3).

1. Z Offending Code

The objective of this method is to convert a string into a date.
Note that I do invoke -release on the NSDateFormatter object, and that the newly created NSDate is destroyed when the NSAutoreleasePool is drained. This is not where the problem lies.

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init]; [dateFormatter setTimeZone:[ NSTimeZone timeZoneWithName:@"GMT"]]; [dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss z"]; [dateFormatter setLenient:YES]; { NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; NSDate *testDate = [dateFormatter dateFromString:string]; // <- Allocates 868 Kb // Do something with testDate [pool drain]; } [dateFormatter release];

2. Discussion

It appears that this is caused by the z option in setDateFormat.
My guess is that Cocoa allocates exactly 8618 time-zone related objects that live in memory for the duration of the application.
I do not know of any workaround, other than not using the “z” option.
[ dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss"];

3. Instruments log

Here is the allocation log for the first 3 of the 8618 objects, allocated all at once by a single invocation to dateFromString. Without going into too much details, suffice it to say that I used “Created & Still Living” option in “Allocation Lifespan”, and that the “Extended Detail” view in Instruments shows that all those objects are created back to back as the result of the CoreFoundation CFDateFormatterGetAbsoluteTimeFromString method.






#
Address
Category
Time
Size
Library
Caller


2280
0xa20be00
GeneralBlock-32
01:07.742
32
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]


2281
0xa219670
GeneralBlock-176
01:07.833
176
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]


2282
0xa298db0
GeneralBlock-48
01:07.833
48
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]

4. All 8618 Objects

The entire log (8618 entries) can be viewed here.

5. Conclusion

The StackOverflow.com positively isolates the problem and the workaround. Do not use setDateFormat:@”EEE, d MMM yyyy HH:mm:ss z“, unless you are willing to loose 868 Kb for the rest of the lifetime of the application. The alternative is to not use the time zone which is, I agree, a pain: setDateFormat:@”EEE, d MMM yyyy HH:mm:ss”.

A possible approach is to test the string against ” GMT”, and to only invoke “z” when not in GMT:
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init]; [dateFormatter setTimeZone:[NSTimeZone timeZoneWithName:@"GMT"]]; if( ![string hasSuffix:@" GMT"]) { // If the string is not GMT, we must use time zone [dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss z"]; } else { [dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss"]; }

As of today’s date iPhone GB cost, your user either $0.005 or $0.01, depending on which device she or he bought.

6. External Links

stackoverflow.com
http://stackoverflow.com/questions/1117263/instruments-leaks-and-nsdateformatter
Developer.apple.com
Your tracking number for this issue is Bug ID# 7745113

Bookmark this on Delicious

Drowning in NSAutoreleasePool

dev — Sun, 15 Nov 2009 19:37:14 +0000

When developing in Cocoa for Mac OS X or for iPhone, it is easy to overlook objects that are dropped in the current NSAutoreleasePool, ultimately leading to a crash. The following article applies to the use of NSAutoreleasePool when garbage collection is not enabled.

Summary

Preventing over-release
[ -retain & -release] vs. [ -autorelease]
Circumventing -autorelease
NSAutoreleasePool is a stack object
NSAutoreleasePool pseudo-code
[pool release] vs. [pool drain]
External links

1. Preventing over-release

There seem to be some unpredictable stability behavior with objects that are released more than once (objects for which the -retainCount drops below 1). At times, some objects sent too many [ release ] will fail silently, whereas occasionally the host application will crash.

An application must balance the number of -retain and -release sent to a NSObject.

SomeObject * myObj = [[SomeObject alloc] init];
...
[myObj release];

To a certain extent, it would be better if over-release would never crash (akin to [ nil release ]) or always crash, thus not hiding bugs during the development stage. The combination of NSZombie and malloc_history is a wonderful tool to debug over-releasing. Read “Debugging Autorelease” on CocoaDev:
http://www.cocoadev.com/index.pl?DebuggingAutorelease

2. [ -retain & -release] vs. [ -autorelease]

Sending -autorelease to an object allows to literally forget about it. [ someObject -autorelease] ensures that someObject with a -retainCount of 1 will remain retained for the life of the NSAutoreleasePool it belongs to, and will receive a -release message when such pool receives -drain or -release. Generally, the question is “Which NSAutoreleasePool ?”. While the answer is “The most nested one, Sir.”, not knowing may lead to surprising behaviors. A defensive approach may be to only create only one NSAutoreleasePool for the entire duration of the application, but this is certainly a costly and rarely practical answer.

-autorelease, contrarily to -release, can be invoked more than once without ill effects.

For some reason, once an object received the -autorelease message, the operation cannot be undone. There is no -unautorelease message. Nor is there a way to tell the NSAutoreleasePool to just forget about that object.

This can lead to the following situations:

Preventing to save/release memory occupied by a given object
Preventing to delete that object at all before deleting the NSAutoreleasePool (sending one-too-many -release will cause the NSAutoreleasePool to send a -release to an already deallocated object, and crash)
Preventing the deletion of a given NSAutoreleasePool, since one cannot know what’s in it.

Following design patterns while being aware of these limitations is generally not a problem. A suggested approach is to use small scopes with local NSAutoreleasePool any time granularity can be achieved. In Cocoa, Threads do just that.

{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    SomeObject * myObj = [[SomeObject alloc] init];
    [myObj autorelease]; // No need to remember about that object
    ...
    [pool drain];
}

3. Circumventing -autorelease

Unfortunately, some Cocoa routines will, without a choice, drop objects it creates in the current NSAutoreleasePool.
Example:

UIImage * newImage = [UIImage imageWithCGImage:some_CGImageRef];

As a result, the caller has little or no control of when the new object will be destroyed. It will likely be deallocated when the NSAutoreleasePool to which it belongs is deallocated, which is generally not predictable.

The NSAutoreleasePool seems to be nothing more than a linked list which sends a -release message to all objects it contains (regardless of their state) upon drain. In a managed memory environment, the pseudo-code of NSAutoreleasePool -drain could be simplified like this:

-(void) drain {
    [autoreleasePool release];
}

Objects that for which the -retainCount is greater than 1 after the -drain will thus not be released. One can take an object out of a pool by retaining it, then releasing the pool entirely. Such object will be effectively removed from the NSAutoreleasePool.
Example:

UIImage * newImage = nil;
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    newImage = [[UIImage imageWithCGImage:some_CGImageRef] retain];
    [pool drain];
}
// The  newImage* is now outside of the pool, and retained normally

An example of this technique can be found on Björn Sållarp’s article “UIImage with round corners”:
http://blog.sallarp.com/iphone-uiimage-round-corners

Note that in the example above, a special scope has been declared around the NSAutoreleasePool creation and destruction. This is good practice since the pool is actually a stack object, and must be created and released in the same { }. Please read on.

4. NSAutoreleasePool is a stack object

By nature, an NSAutoreleasePool instance is stored on the stack (as opposed to the heap). As a direct consequence, the scope of these pools, and ultimately of the objects they reference, are tightly coupled with the methods that created them. Even though the pools (just like the invocation of methods) are nested, there is no virtual stack of NSAutorelease pools.

As the method that created a given pool goes out of scope, so does that very pool, and all the objects referenced by it will receive a single -release message. For an object to survive a pool drain, it must be explicitly retained. See paragraph 3, Circumventing -Autorelease.

Being a stack object also makes it illegal to create an NSAutoreleasePool instance in a method, and to release it in another. This reason alone can serve as a good motivation for creating small, local and nested NSAutoreleasePool rather than one gigantic one for the life of the Thread.

5. NSAutoreleasePool pseudo-code

In a managed memory environment, the NSAutoreleasePool acts pretty much like a NSArray. The pool maintains strong references to its content. Objects added to the pool receive a -retain message.

Possible pseudo-code for NSAutoreleasePool


 // .h
@interface NSAutoreleasePool2 : NSObject {
@private
    NSMutableArray * autoreleasePool;
}
-(void) drain;
-(void) addObject:(id)anObject;
-(id) autoreleaseObject:(id)anObject;
@end

// .m
@implementation NSAutoreleasePool2
-(id)init {
    if ((self = [super init] ) != nil ) {
        autoreleasePool = [[NSMutableArray alloc] init];
    }
    return self;
}
-(void) dealloc {
    [self drain];
    [super dealloc];
}
-(void) drain {
    [autoreleasePool release];
}
-(void) addObject:(id)anObject {
    [autoreleasePool addObject:anObject];
}
-(id) autoreleaseObject:(id)anObject {
    if( ! [autoreleasePool containsObject:anObject]) {
        [self addObject:anObject];
    }
    return anObject;
}
@end

Discussion

This is pseudo-code, not actual NSAutoreleasePool source code.
Objects must be added explicitly to this pool (using [pool autoreleaseObject:someObject ]; instead of [someObject autorelease];)
-autoreleaseObject is lenient, and will not penalize objects added more than once.
-addObject is strict ; objects added more than once will receive -release more than once.
-drain and -release do not have the same behavior. This pseudo-code expects an invocation to [pool release ] rather than [pool drain ] to free the NSAutoReleasePool2.

6. [pool release] vs. [pool drain]

In a reference-counted environment sending -release or -drain to a NSAutoreleasePool has the same effect.

In a garbage-collection environment, without NSAutoreleasePool, -release has no effect while -drain triggers garbage collection. For this reason, the developer documentation explicitly recommends using -drain, since it has a meaning in both management models, even on iPhone.

Read more about NSAutoreleasePool -drain on Apple’s developer site:
http://developer.apple.com/mac/library/documentation/cocoa/reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html

7. External links

Bookmark this on Delicious

#	Address	Category	Time	Size	Library	Caller
2280	0xa20be00	GeneralBlock-32	01:07.742	32	Foundation	-[NSDateFormatter getObjectValue:forString:range:error:]
2281	0xa219670	GeneralBlock-176	01:07.833	176	Foundation	-[NSDateFormatter getObjectValue:forString:range:error:]
2282	0xa298db0	GeneralBlock-48	01:07.833	48	Foundation	-[NSDateFormatter getObjectValue:forString:range:error:]