When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth

When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth

The other day, I was in need of a Cocoa application that launches quickly that has a standard document model. At random, I chose the rather awesome Hex Fiend. As I often do, I also had top -u -o pid running in a Terminal window.

And I noticed something odd. As expected, the RPRVT of Hex Fiend was growing on each cmd-n. However, the RPRVT was not decreasing the same amount every time I hit cmd-w.

That ain’t right. Or it might be. Beyond evidence that a memory use problem may exist, top is a horrible tool for determining if a problem is real or what the actual problem might be.

In this case, the issue looks like a simple memory leak. Hex Fiend is allocating and retaining some set of objects, but not releasing them. The easiest first step is to use the leaks command line tool:

% leaks "Hex Fiend"
leaks Report Version:  2.0
Process:         Hex Fiend [3435]
Path:            /Volumes/Data/Applications/Hex Fiend.app/Contents/MacOS/Hex Fiend
Load Address:    0x100000000
Identifier:      com.ridiculousfish.HexFiend
Version:         2.0.0 (200)
Code Type:       X86-64 (Native)
Parent Process:  launchd [122]
Date/Time:       2010-10-16 20:47:09.935 -0700
OS Version:      Mac OS X 10.6.4
Report Version:  7
Process 3435: 22980 nodes malloced for 2600 KB
Process 3435: 0 leaks for 0 total leaked bytes.

OK; whatever the problem is, it isn’t “leaked” memory in the traditional definition of “leaked memory”.

That is, whatever memory is being allocated and never released is still being referenced somewhere. Maybe a circular retain. Maybe something that has a weak reference from the rest of the App’s object graph such that leaks can’t detect.

In other words, this isn’t just a simple memory leak and it will require more advanced tools to fix.

Fortunately, the Allocations Instrument provides exactly the tool we need. It is called Heapshot Analysis and it is brutally effective at deducing these kinds of problems.

To use:

• Launch Instruments and select the Allocations template under the Memory category.
• Target the application you want to analyze. It can already be running or you can launch it from Instruments. As well, you can launch it from Xcode via the Run With Performance Tools menu.
• (10) Do something in the application where you return to the starting state. For Hex Fiend, this particular case is as simple as creating a new document and then closing it. For an optimal application, this activity should effectively cause no memory growth (or very little).
• In the Allocations Instrument, press the Mark Heap button
• Goto 10 (and repeat 5 or 6 times).

I ended up with the data as seen to the left. Each “Heapshot” iteration represents opening, then closing, an untitled window with no data in it.

The “Heap Growth” and “Still Alive” columns provide a summation of all of the objects in that heapshot that still exist in all subsequent samplings of the heap. That is, inHeapshot 3, there were 36.08K of allocations spread across 260 allocation events that continued to exist throughout the rest of the run.

Specifically: the values in those columns representpermanent heap growth.

When creating, then closing, an untitled document there should be, ideally, no heap growth. That there is ~35K per document of permanent heap growth indicates that a leak does exist (regardless of what leaks said above).

Note that as you continue to iterate, you might see the values of previous Heapshot samples decrease. That is because objects allocated in that sample — at that heap mark — have been released. That is, every single object listed in that table — all ~25,000 or so in that screenshot alone — are very much in memory, using resources, and sticking around.

Instruments lets us dive deeper.

Not only can we expand any given Heapshot iteration to see the inventory of permanent objects allocated in that iteration, but we can dive all the way down to the individual allocations and see a backtrace of exactly where it was allocated.

Looking at many of the allocations, they all seem to be during either the initialize of an instance of MyDocumentor during loading of the user interface related with the same.

No surprises there; the inventory of objects is clearly related to the document.

What is surprising, though, is that an instance of MyDocument doesn’t show up on that list! It looks like the instance of MyDocument is correctly being deallocated on window close, but much of the user interface related to the document is not!

While we clearly have enough evidence to suspect MyDocument as being the source of the issue, we can confirm this further within Instruments.

Turn on Record reference counts in the Allocations instrument. When the app isn’t running, hit the little (i) in the Allocations track in Instruments and click the check box. Then run the application and do the same set of samples (or turn this on from the beginning if you didn’t forget like I did).

Now, when you click through any allocation, you’ll see a list of events that includes the point of allocation and all subsequent retain/release events. Clicking through many of the random objects in any given Heapshot sample shows two things. First, all of the objects ended with a retain count of 1 — not 2, not 5, but 1 — this indicates that whatever the problem is, it is likely pretty consistent and we can fix it once and be done with it. Secondly, the non-UI related objects like DataInspector or NSBigMutableString have very few events and they largely come from[MyDocument -init], further confirming our suspicions.

Now it is time to turn to the source.

Which I need to download; all of the above was done against the app without the source.

OK — got it — now — start with MyDocument‘s init method (which doesn’t do the self = [super init]; if (self) {...} return self;dance. Boo.) and compare it to dealloc

The init method looks fairly straightforward; allocate a bunch of stuff, glue it together, return self:

- init {
    [super init];
    lineCountingRepresenter = [[HFLineCountingRepresenter alloc] init];
    hexRepresenter = [[HFHexTextRepresenter alloc] init];
    asciiRepresenter = [[HFStringEncodingTextRepresenter alloc] init];
    scrollRepresenter = [[HFVerticalScrollerRepresenter alloc] init];
    layoutRepresenter = [[HFLayoutRepresenter alloc] init];
    statusBarRepresenter = [[HFStatusBarRepresenter alloc] init];
    dataInspectorRepresenter = [[DataInspectorRepresenter alloc] init];
    ... etc ...

As a matter of fact, pretty much all of those representers are showing up as still in memory per each Heapshot mark!

And, diving into the individual retain/releases, we see that some of the representers are connected to other representers. So, if anyone of those representers is sticking around, it might likely keep others alive with it, too! Or it could be a circular retain issue. But, before we start trying to deduce hard problems, we should exhaust the simple causes first and look at the dealloc method.

The first thing that jumps out at me is that the dealloc method is trying to do something clever. Instead of line-by-line calling release on every object allocated in init, it does:

    [[self representers] makeObjectsPerformSelector:@selector(release)];

OK. So, what does representers look like?

- (NSArray *)representers {
    return [NSArray arrayWithObjects:lineCountingRepresenter, hexRepresenter,
               asciiRepresenter, scrollRepresenter,
               dataInspectorRepresenter, statusBarRepresenter, nil];
}

Waitaminute there…. comparing that array’s contents to the items allocated in init, we see that the layoutRepresenter is missing. Nor is it explicitly released anywhere else in dealloc!

That’d be the leak right there! And leaks won’t detect it because there are enough non-retained relationships that the objects look like they are still reachable from the application’s core object graph!

The naive fix would be to add layoutRepresenter to the array returned by -representers. However, the layoutRepresenter seems to be kinda special in its role and, frankly, I really hate tricky dealloc games like making an array of objects perform release.

So, I replaced the performSelector: in dealloc with:

    [lineCountingRepresenter release];
    [hexRepresenter release];
    [asciiRepresenter release];
    [scrollRepresenter release];
    [layoutRepresenter release];
    [statusBarRepresenter release];
    [dataInspectorRepresenter release];

Running the heapshot analysis again shows that the # of permanent allocations per iteration has dropped from ~250 to a consistent 8. Vast improvement, but still not perfect.

Looking at the remaining allocations, every single one is allocated in drawLineNumbersWithClipStringDrawing.

In particular, it is the drawing call here that is the source of the remaining leaks (except one):

	    NSString *string = [[NSString alloc] initWithBytesNoCopy:buff
						length:newStringLength
						encoding:NSASCIIStringEncoding freeWhenDone:NO];
            [string drawInRect:textRect withAttributes:textAttributes];
            [string release];

But, wait, how can that be? Well, it could be a bug in the AppKit. Or it could be some kind of a weird cache. As a matter of fact, if you create about 30 documents in Hex Fiend, then close them all, you will see the previous heap marks drop to 7 objects remaining. So, clearly, there is some kind of a size limited cache that is eventually being pruned. Obviously, not a very efficient cache if it is filling with copies of the same objects. I like to call these kinds of caches write only caches. All the benefits of high memory use combined with all the efficiencies of a 100% cache miss rate! FTW!

The one other leak, though, is that the dealloc method in HFLineCountingView is not releasing the textContainer. First, I’ll fix that and re-measure. Done. That removes one object from each Heapshot iteration.

OK — so, looking at the remaining objects, we have a set of objects that look an awful lot like a set of attributes for text; a paragraph style, color, etc…

Sure enough, textAttributes is not being released in dealloc.

So, where do we stand?

See for yourself!

Not bad! No leaks on many iterations. That 1 4KB malloc seen in some iterations is likely some internal cache in the AppKit. That it doesn’t always appear and eventually goes away indicates that it is both behaving correctly and can be ignored.

The next step would be to do the same kind of testing, only with documents that contain actual data. Then do the testing after making a set of edits and undoing them.

---

Heapshot analysis has proven to be an incredibly effective tool for identifying and fixing memory use issues in applications. The above style of use where you pick a task that should return state back to the same as it was when you started is the most effective form of this analysis.

However, this same approach can be used for applications that build up or change state over time (think Mail, which has new messages coming in all the time or an application with an accretion of logs or undo state).

Fire up your application under Instruments and periodically hit “Mark Heap” when your app is in a reasonable state. The more Heap Shots you capture, the easier it is to analyze. Look at any given iteration and ask yourself Why do these objects created way back when still exist in memory and is their use of resources justified?. The follow up question is What can I do to make the permanent memory accretion smaller?.

 

From: http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/