Bill Bumgarner

Eric Peyton wrote a brilliant post that summarizes the use of leak and the malloc debugging tools built into OS X to track down memory leaks.

To summarize:

In a Terminal window....

 setenv MallocStackLogging /path/to/foo.app/Contents/MacOS/foo 

... you should see a diagnostic message like ...

 malloc[PID]: recording stacks using standard recorder 

... then, in another Terminal window...

 leaks PID 

... do whatever it is in the app that you suspect causes leaks. The leaks process will print detailed information about the leak, including the backtrace of the appropriate thread within the application at the time the memory was allocated.

As Eric points out in a later post, if you find a leak in the AppKit or other library code, make sure it isn't a code path through your own code that is the real cause of the leak. Apple is generally very good about making sure the various frameworks don't leak memory, but that assumes that the API is being called in the proper fashion.

Some useful man pages:

leaks - Search a process's memory for unreferenced malloc buffers
heap - List all the malloc-allocated buffers in the process's heap
malloc - memory allocation
malloc_history - Show the malloc allocations that the process has performed
MallocOptions - Malloc options release notes
Memory Performance - Memory Management & Memory Optimization guide