Static Analysis: tweaks to data model and added cpychecker support

David Malcolm dmalcolm at
Wed Jan 30 16:53:26 UTC 2013

Short version:
Updates to "mock-with-analysis" [1]:
  (a) changes to the data model
  (b) cpychecker support added

Longer version:
I've been hacking on "mock-with-analysis", my tool for running static
code analysis as a side-effect within a regular srpm rebuild (see [1]).

I've tweaked the data model (the "firehose" XML format [2]): before, we
were outputting one XML file every time an analysis tool found a
problem.  This approach doesn't capture coverage: we wouldn't know which
tools were run on which code.  So I've reworked things so that each XML
file represents a run of an analysis tool on a source file, and contains
zero or more issues (all in a common XML format).  It also can contain
stats e.g. the wall-clock time of how long the analysis tool on that
file.  We probably should extend it to capture other metadata like what
arguments were passed to GCC (e.g. the -W options).

I've also been working on the "cpychecker" analyser [3] that's part of
my gcc-python-plugin.  This is an analyzer for C code.  It looks for
common mistakes in usage of the CPython extension API, such as
reference-counting bugs.

The "firehose" branch of the gcc-python-plugin [4] now uses the firehose
Python API as the internal representation format within cpychecker, and
can thus "natively" emit XML files in our format, and I've hooked it up
in mock-with-analysis so it gets run on all C code.

So the mock-with-analysis prototype now has the following run in a mock
  * cppcheck
  * clang-analyzer
  * gcc warnings
  * cpychecker

You can see an example of the output here:

As before, it's the results from mock, with a new "static-analysis"
directory containing XML result files, and any source files mentioned in
the results (grep for "FAKE-GCC" in the build.log to see copious debug
spew from the analysis tools).  The raw XML results can be seen here:
though most of them are empty (most source files had no issues).

To make things slightly easier to read, I wrote a primitive HTML
summarizer, and you can see the (ugly) result here:

Note though that this output is really just for debugging.  (In
particular, it's violating my #1 UI requirement, which is that any time
I see an analysis report, I want to also see the *code* so that a
developer can easily determine if she needs to act on the report -
though the sources have been captured - it's just a case of writing a
nice UI to this).

(Note that this version of cpychecker can emit reports showing a trace
of execution needed to reach certain error, and this makes it into the
XML - it's just that no such errors were present in this rpm).

Next steps are to try running it on more packages, to make things more
robust, and to build a good UI (e.g. to present a comparative view of
two builds: "what new warnings appeared?" etc).

If you're interested in getting involved, I've started making a list of
things to try here:


[1] see

More information about the devel mailing list