Posted By Quentin Carnicelli on July 14th, 2008
In recent years, my patience has increased such that I’m now often content to wait for software to be out of beta before trying it. But some things are just so good that even in their early, buggy stages, putting up with their beta-ness is well worth it. That certainly is the case with the Clang Static Analyzer.
You may have heard about it at WWDC, or when it made the rounds last week. In short, Clang Static Analysis is like an extended set of compiler warnings for your code (C and Obj-C as of this writing). However, the Clang Checker has a vastly better understanding of your code than a compiler. It can detect memory leaks, double-frees, bad pointer references, and other such bugs that keep you up at night.
When run, the checker produces nice interactive HTML reports. Here’s an image of the report for Nicecast:
We choose not to display the Dead Stores and Missing Deallocs, as they are rarely bugs (at least for our code). Some of the memory leaks are false positives as the checker is confused by some things, like objects that live for the lifetime of the application. But that memory leak listed for PMRunLoop.c was real. Clicking on “View” link gives the following:
As you can see, this is a very nice syntax colored HTML listing of the source, with comments inserted showing how the leak occurs. In this case the bug is obvious: we commented out the call to Release and forgot to undo it later. In other cases the checker has found leaks for us in far more subtle places, such as large recursive functions with multiple exit points.
On our first run over our entire code base (nearing half a million lines), Clang found one major crashing bug in Nicecast that had been plaguing us for awhile, several other possible crashers in our various frameworks, and more memory leaks then you can shake a stick at (although most were in edge cases such as error handling).
After fixing all these problems, we went and re-ran the checker to generate new reports. With almost forty separate projects to run the checker on, we realized that automating this would probably be preferable. So I invested some time upgrading our build system such that it generates checker reports nightly, and posts them to our development wiki and nightly builds RSS feed. Now, each day, we get a report like this:
While I am still hesitant about beta software, especially beta development tools, I very much recommend the Clang static checker to all developers. The amount of time it takes to use it is dwarfed by the time it saves in improving the quality of your code.