gcc-python-plugin status update: static analysis, and HTML reports

[David Malcolm <dmalcolm at redhat dot com>]

I've written up a status update on the gcc-python-plugin on my blog
here:
http://dmalcolm.livejournal.com/6560.html

Summarizing that blog post, I've revamped the internals of how my
checker script so that it can detect various kinds of CPython reference
count bug, and it can now render bug reports as both regular text on
stderr, and in HTML form:
http://fedorapeople.org/~dmalcolm/blog/2011-07-15/refcount_demo-refcount-errors.html

(you may need a modern browser to see the control flow annotations in
the HTML, as it uses JavaScript and the <canvas> element; there are
screenshots in the blog post)

Detecting the all-too-common: "return Py_None;" bug:
http://fedorapeople.org/~dmalcolm/blog/2011-07-15/losing_refcnt_of_none-refcount-errors.html


Detecting a (contrived) reference leak:
http://fedorapeople.org/~dmalcolm/blog/2011-07-15/object_leak-refcount-errors.html


Detecting a stray Py_INCREF that makes the reference count too high, or
segfaults python, depending on what happened earlier within the
function:
http://fedorapeople.org/~dmalcolm/blog/2011-07-15/too_many_increfs-refcount-errors.html


Some of that rendering code might be of use to other users of the
plugin; has anyone else rendered HTML reports from within GCC?


I didn't discuss implementation details in the blog post, but given the
audience on these lists, it's probably on-topic to mention here:

It works by a rather crude implementation of abstract interpretation,
tracking all possible paths through the function, generating traces of
execution.  (It currently will fail horribly when it encounters a loop;
I suspect I need widening/narrowing operators, and to read a lot more
papers on the subject :) )

Internally, the analyser models the memory state using a method similar
to the one used by LLVM's clang static analyser, as described in:
"A Memory Model for Static Analysis of C Programs" (Zhongxing Xu, Ted
Kremenek, and Jian Zhang)

thus handling pointers and dereferences (though my implementation is
very much an early prototype as this stage).

I've added a new (as far as I know) class of abstract value representing
"all reference counts that the function owns" (i.e. an integer value,
relative to the unknown refcount owned by all of the rest of the
program).


Hope this is helpful/interesting
Dave