Static Analysis: tweaks to data model and added cpychecker support
dmalcolm at redhat.com
Wed Jan 30 16:53:26 UTC 2013
Updates to "mock-with-analysis" :
(a) changes to the data model
(b) cpychecker support added
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 ).
I've tweaked the data model (the "firehose" XML format ): 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  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
The "firehose" branch of the gcc-python-plugin  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
* gcc warnings
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:
More information about the devel