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