ansaurus

Question

Making sense of the 'leaks' command line utility for finding memory leaks

Answer 1

A:

For this example, leaks reports 3 leaks for a total of 128 bytes. The interpretation should be as follows:

1) you are leaking a NSMutableString which appears to be implemented internally as NSCFDictionary for a total of 64 bytes

2) you are leaking Testing 1 for a total of 32 bytes

3) you are leaking \nTesting 2 for a total of 32 bytes

This should be because if you do not release your NSMutableString, none of the objects (strings in this case) belonging to the NSCFDictionary data structure will be released: they are retained each time you use the appendString method. When you release your NSMutableString, all of the object inside NSCFDictionary are automatically released, along with the NSCFDictionary itself.

From the Apple documentation (http://developer.apple.com/iPhone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html):

If a Cocoa object is autoreleased without an autorelease pool in place, Xcode sends an a message to the console warning you that the object is just leaking. Even if you are not writing a Cocoa application, it is possible to see this same type of console warning. The implementation of many Cocoa classes is based on Core Foundation types. If your application uses Core Foundation, it is possible that the leaks are occurring as a result of calls to that framework.

To find memory leaks of this type, use the debugger to put a breakpoint on the _NSAutoreleaseNoPool function. This function is declared in NSDebug.h in the Foundation framework. When the debugger reaches that function, you should be able to look at the stack crawl and see what piece of code caused the leak.

unforgiven 2009-04-17 17:02:22

Answer 2

+1 A:

I think the reason you are seeing this in leaks is because appendString is using autorelease internally. The autorelease pool isn't being discarded until the next 'event'. Basically, I think the sample is too simple to accurately show what's going on.

I could be way off base here, but I would try wrapping your code in an autorelease pool to see what changes.

-(void)applicationDidFinishLaunching:(NSNotification *)notification;
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    NSMutableString *test = [[NSMutableString alloc] init];
    [test appendString:@"Testing 1"];
    [test appendString:@"\nTesting 2"];
    NSLog(@"%@", test);
    [test release], test = nil;
    [pool release] // this should drain the autorelease pool
}

Jab 2009-04-17 17:45:57

Answer 3

+2 A:

There is no stack trace in the output you showed. The addresses you see are the objects' own addresses, not function pointers, and the hex numbers next to the punctuation characters are simply the hex dump of the data.

To find out where the object was allocated from, set MallocStackLogging in leaks's environment:

% MallocStackLogging=1 leaks …

You may also want to use the -nocontent option, which will suppress the hex dump. Don't use this all the time, however: Sometimes the hex dump contains a valuable clue.

Also, leaks is not necessarily telling you that you have three leaks; to be precise, it's telling you that you have three leaked objects. The deliberate leak you showed produces only one leaked object, but a different leak (such as in a loop or frequently-called method) may leak many objects.

Edit: BTW, some of those leaks are from SIMBL or one or more of your SIMBL plug-ins. Turn off SIMBL and any other input manager hacks before leak-hunting. Remember, that code runs in your process; moreover, leaks doesn't care whose code allocated or leaked the memory, only that it's leaked, so it will show the leaked object regardless of who allocated or leaked it.

Peter Hosey 2009-04-17 20:16:19

Thanks Peter. I have no idea with SIMBL is, but I'll look it up.

2009-04-19 18:59:02

ansaurus

tags:

views:

answers:

Making sense of the 'leaks' command line utility for finding memory leaks

related questions