chanson

A developer on the comp.lang.objective-c newsgroup asked recently how to check his Cocoa application for memory leaks.

Here's a simple process for using the leaks(1) command-line tool to investigate leaks in your applciation.

1. Add some code to your application to wait instead of exiting, such as an atexit(3) callback that just sleeps:

     while (1) sleep(60);

   This ensures that your application stays around after it has otherwise completley shut down.

2. Launch your application with the MallocStackLogging environment variable set to 1. You can set this by inspecting the executable — not the target — for your application. (See the malloc(3) manpage for more details on the environment variables that you can use with it.)

3. Launch your application from within Xcode, run through a series of actions in your application, and quit your application. It should now be paused in your atexit(3) callback.

4. Run /usr/bin/leaks against your sleeping application by specifying your sleeping application's process ID as its argument.

This will give you a list of blocks that leaks(1) thinks have been leaked from your application, their contents, and — thanks to the MallocStackLogging environment variable — the stack trace at the point each leaked block was allocated!

You can even do post-processing on this output to do things like format the stack traces and automatically file bugs against your application. Heck, you could even have your application have a debugging mode that launches leaks(1) And the best part: This isn't specific to Cocoa. It will work for Cocoa, Carbon, and even Unix tools. Anything that uses the standard system malloc(3) can be checked this way.