When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth
2013-06-05 09:36
543 查看
When
is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth
come from:bbum'sweblog-o-mat
link:http://www.friday.com/bbum/2010/10/17/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 pidrunning 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,
topis
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 Fiendis allocating and retaining some set of objects, but not releasing them. The easiest first step is to use the
leakscommand
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).
![](http://www.friday.com/bbum/wp-content/uploads/2010/10/Step-1.png)
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, in Heapshot
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 represent permanent 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.
![](http://www.friday.com/bbum/wp-content/uploads/2010/10/Step-2.png)
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
MyDocumentdoesn’t
show up on that list! It looks like the instance of
MyDocumentis
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
MyDocumentas
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
initmethod
(which doesn’t do the
self = [super init]; if (self) {...} return self;dance. Boo.) and compare it to
dealloc
The
initmethod
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
deallocmethod.
The first thing that jumps out at me is that the
deallocmethod
is trying to do something clever. Instead of line-by-line calling
releaseon
every object allocated in
init,
it does:
[[self representers] makeObjectsPerformSelector:@selector(release)];
OK. So, what does
representerslook
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
layoutRepresenteris
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
layoutRepresenterto
the array returned by
-representers.
However, the
layoutRepresenterseems
to be kinda special in its role and, frankly, I really hate tricky
deallocgames
like making an array of objects perform
release.
So, I replaced the
performSelector:in
deallocwith:
[lineCountingRepresenter release]; [hexRepresenter release]; [asciiRepresenter release]; [scrollRepresenter release]; [layoutRepresenter release]; [statusBarRepresenter release]; [dataInspectorRepresenter release];
![](http://www.friday.com/bbum/wp-content/uploads/2010/10/Step-3.png)
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
deallocmethod
in
HFLineCountingViewis
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,
textAttributesis
not being
released
in
dealloc.
![](http://www.friday.com/bbum/wp-content/uploads/2010/10/Step-4.png)
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?.
This entry was posted on Sunday, October 17th, 2010 at 3:20 pm and is filed under Mac
OS X, Objective-C, Software, Tools, Xcode.
You can follow any responses to this entry through the RSS
2.0 feed. You canleave
a response, or trackback from
your own site.
相关文章推荐
- When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth
- Downloading files from a server to client, using ASP.Net, when file size is too big for MemoryStream using Generic Handlers (ashx)
- 错误:created a ThreadLocal with key of type ……but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
- Using the Kernel Debugger to Find a Kernel-Mode Memory Leak
- Howto find native code memory leak in Android
- Sybase- Could not find SQL statement to include with refid 'getOrderInHdStatisDetailsql'
- tomcat启动报错,JDBC注册失败:This is very likely to create a memory leak
- 关于Error:Minifying the variant used for tests is not supported when using Jack.
- ORA-04030: out of process memory when trying to allocate 64544 bytes (sort subheap,sort key)
- If you have multiple web application run how to determin which is yours when you debug using visual studio 2008?
- field is not Date/numeric when export excel using reporting service
- Linux环境Tomcat 启动警告This is very likely to create a memory leak.
- [VMware]关于VMware出现Not enough physical memory is available to power on this virtual machine
- The origin server did not find a current representation for the target resource or is not willing to
- Using ATL is simple,but to understand it is not easy.
- The IP you're using to send email is not authorized
- How To Find Where The Memory Is Growing For A Process (Doc ID 822527.1)
- Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath.Perhaps JAVA_HOME does not point to the JDK
- 问题:Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath.Perhaps JAVA_HOME does not point to the JDK
- 由一个自动部署脚本引发的血案。。。This is very likely to create a memory leak