State of Static Analysis At Mozilla

Mozilla has static analyses built into the buildsystem that can be turned on with –with-static-checking= flag. The analyses live in xpcom/analyses directory. The testcases (aka documentation) are in xpcom/tests/static-checker. Analyses are implemented in either Dehydra or Treehydra and run within a patched GCC 4.3.

The currently landed checks are:

  • final.js: Java-like “final” keyword for C++
  • flow.js: Ensure code in a function flows through a particular label
  • must-override.js: Force derived classes to override certain methods
  • override.js: Ensure methods exist in base class
  • outparams.js: Ensure outparameters and return error codes are in sync
  • stack.js: Mark classes as stack-only

A whole lot more analyses in various states of completion can be tracked in the static analysis bug.

Asynchronous discussion happens in the mailing list. #static irc channel is the place for interactive discussion.

Nearterm Plans For Plugins

GCC 4.5 has an official plugin framework enabled by default. I will try to switch to GCC 4.5 as soon as it is out. Currently 4.5 is still changing too often for me to bother fixing Treehydra (Dehydra usually works). As soon as 4.5 is out I will revise the installation instructions to use distribution GCC and JavaScript packages to avoid the current mess (draft can be found here). Sometime after that I’ll switch Mozilla static analysis to GCC 4.5 and drop 4.3 support.

Hopefully, this will make it easier for other open source projects to adapt the hydras.

Plans for Analyses

I’m a big believer into application-specific static analyses, but I would like to see some heavy duty open source analyzers built on top of GCC.

Some of the not-so-Mozilla-specific analyses should be bundled together to make them easy to try out on other projects.

Hopefully 2010 will be the year that open source static analysis catches on.

LCA2010

I posted my slides from yesterday.

2 comments

  1. There are a few things I am curious about.

    I’d like to hear more about what kinds of analyzers you think should be built.

    Have you tried the clang analyzer?

    I think it would be pretty useful to have a GCC wish-list of things that would help your analysis efforts. I only saw one bug in bugzilla … but that can’t be all there is.

  2. > Some of the not-so-Mozilla-specific analyses should
    > be bundled together to make them easy to try out
    > on other projects.

    bug 427115 would almost certianly be such an analysis. Definitely applicable to Tamarin and Flash.