firehose-devel February 2013

firehose-devel@lists.fedoraproject.org

4 participants
13 discussions

JSON serialization
by David Malcolm 27 Feb '13

27 Feb '13

I've implemented JSON support for Firehose - as of: https://github.com/fedora-static-analysis/firehose/commit/453f1944552bdc127… everything has a to_json and from_json method, and the unit tests verify that everything roundtrips cleanly from Python objects through JSON back to Python objects. I've been using this to slurp large numbers of results into a MongoDB database, similar to the "storz" work that Paul posted here. I'm not sure how much I like this approach - I'm much more familiar with SQL, so that aspect is experimental for now. [I much prefer XML as the serialization format, given that we can validate files against the schema] Dave

2 1

<issue> can now have a <customfields>
by David Malcolm 25 Feb '13

25 Feb '13

This was too useful not to implement, so as of: https://github.com/fedora-static-analysis/firehose/commit/3fb95bd1c4969baf1… it's now possible for an <issue> to store custom key/value pairs. I'm using this in cpychecker to gather information on format-string misuses across hundreds of packages (to avoid the need to parse my messages with regexps). With that, all of <issue>, <failure>, <info> and <analysis> can store <custom-fields>. Hope this is useful Dave

1 0

[PATCH 1/2] mock-with-analysis: do not hard-wire rpm top directory
by Kamil Dudka 18 Feb '13

18 Feb '13

--- mock-with-analysis | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/mock-with-analysis b/mock-with-analysis index 9964c45..9390fb0 100755 --- a/mock-with-analysis +++ b/mock-with-analysis @@ -96,9 +96,12 @@ def setup_chroot(mockcfg, srpmpath): mockcfg.cmd(['--install', 'cppcheck']) mockcfg.cmd(['--install', 'clang-analyzer']) + # Read the rpm top directory (e.g. /home/david/rpmbuild) + rpmtopdir = Popen(["rpm", "--eval", "%{_topdir}"], stdout=PIPE).communicate()[0].rstrip() + # Install the pre-built gcc-python-plugin (from the firehose branch): mockcfg.cmd(['--install', - '/home/david/rpmbuild/RPMS/x86_64/gcc-python2-plugin-0.11.firehose-1.fc17.x86_64.rpm']) + rpmtopdir + '/RPMS/x86_64/gcc-python2-plugin-0.11.firehose-1.fc17.x86_64.rpm']) # Copy up latest version of the libcpychecker code from a working copy # overriding the copy from the pre-built plugin: @@ -113,7 +116,7 @@ def setup_chroot(mockcfg, srpmpath): # FIXME: package these and get them into Fedora: mockcfg.cmd(['--install', '../firehose/dist/firehose-0.0.1-1.noarch.rpm']) mockcfg.cmd(['--install', '../gccinvocation/dist/gccinvocation-0.0.1-1.noarch.rpm']) - mockcfg.cmd(['--install', '/home/david/rpmbuild/RPMS/x86_64/python-subprocess32-3.2.3-1.fc17.x86_64.rpm']) + mockcfg.cmd(['--install', rpmtopdir + '/RPMS/x86_64/python-subprocess32-3.2.3-1.fc17.x86_64.rpm']) # ^^^ review request for python-subprocess32: # https://bugzilla.redhat.com/show_bug.cgi?id=910891 -- 1.7.1

1 1

Storing results in a DB
by Paul Tagliamonte 14 Feb '13

14 Feb '13

Hello, Firehosen, So, forewarning: This is all very very hackey and gross. I wrote a small native-object converter[1], which uses __slots__ to populate a dict of dicts (it looses a bit of data, but is otherwise rad), in order to store the entire Firehose report in a MongoDB document datastore. I've only loaded Debian's Chromium build-logs, but I plan on doing a full run this weekend, if all goes well. > db.results.find().count() 211 > db.results.find({"results.location.file.givenpath": "third_party/libphonenumber/src/phonenumbers/utf/unicodetext.cc"}).count() 51 > db.results.find({"metadata.sut.buildarch": "armhf"}).count() 22 Two things: 1) This is gross. I don't like how I'm converting to Pythonic objects. Who's +1 / -1 on adding this as a top-level method like to_xml & from_xml ? 2) I like Mongo, a lot. Would anyone mind if I supported it more? I can work with PostgreSQL or another relational DB, but I've grown to love MongoDB the more I use it :) Cheers, Paul [1]: https://github.com/paultag/storz/blob/master/storz/decompress.py https://github.com/paultag/storz/blob/master/storz/store.py -- .''`. Paul Tagliamonte <paultag(a)debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag

1 0

Initial cut at a Debian package linting wrapper for Firehose
by Paul Tagliamonte 14 Feb '13

14 Feb '13

Hello, Firehosen, I've just hacked a basic wrapper around one of the most used Debian tools; Lintian. It's currently brokenish (need to work out some stray Nones in the schema), but should be good to go shortly. Check it out on GitHub[1] While wrapping it, I also added some helper functions which could use some feedback. They're very Debian-centric, but could be simply adapted for Firehose proper if we decided on that. Cheers, Paul P.S., for those who missed the joke, see[2] [1]: https://github.com/paultag/storz/blob/master/wrappers/storz-lintian [2]: http://en.wikipedia.org/wiki/Storz -- .''`. Paul Tagliamonte <paultag(a)debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag

2 5

firehose: Please add a configuration sub-element to the generator
by Florian Weimer 14 Feb '13

14 Feb '13

Some tools produce vastly different output based on configuration settings. It would be nice to have some indication about the configuration used. It might also make sense to differentiate between the actual tool and the generator which translates tool-specific output to the firehose representation. -- Florian Weimer / Red Hat Product Security Team

1 0

travis-ci.org
by David Malcolm 12 Feb '13

12 Feb '13

I added firehose to the continuous integration service at travis-ci.org We're green as of: https://travis-ci.org/fedora-static-analysis/firehose/builds/4755286 Dave

1 0

Adding an <info> tag?
by David Malcolm 12 Feb '13

12 Feb '13

Currently we have two kinds of result within an <analysis>: * <issue> elements, representing a warning from an analysis code about a possible problem with the software-under-test (SUT) * <failure> elements, representing a report about a failure of an analysis tool to achieve full coverage of the SUT (e.g. the tool crashed or timed out) I'm thinking it might be useful to be able for an analyzer to record arbitrary extra information about the software-under-test, where it isn't an issue as such, but for custom data-gathering about the SUT, so I'm considering adding an <info> element as a third type of result, with an optional <location> and allowing storing <custom-fields>. The motivating use-case for me is in my mass-analysis of Python extension modules: I though it might be interesting to gather some stats on uses of the CPython API, and it's not a bit stretch to add this to cpychecker's firehose output. Perhaps one could use this to build an lxr-style indexing tool also. Thoughts? Dave

2 2

Tweaks to <failure> element
by David Malcolm 08 Feb '13

08 Feb '13

I'm trying to make my data-gathering more robust in the face of analysis failures, so am tweaking the <failure> element. This commit is hopefully self-explanatory: https://github.com/fedora-static-analysis/firehose/commit/a889e8c68371f9110… Dave

1 2

Re: Static Analysis: some UI ideas
by David Malcolm 06 Feb '13

06 Feb '13

On Mon, 2013-02-04 at 15:04 -0500, David Malcolm wrote: > I've been experimenting with some UI ideas for reporting static analysis > results: I've linked to two different UI reports below. [...snip...] I've updated the reports somewhat so that they can now show analysis failures were an analyzer fell over. (currently this failure data is only supplied by cpychecker, but I plan to wrap things in mock-with-analysis so that if something segfaults or otherwise fails we capture it, rather than drop it on the floor). Updated version of the simple report: http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-06/simple-report-… Updated version of the comparative report: http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-06/comparative-re… For example, see: http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-06/comparative-re… where cpychecker failed with an exception in the same place when analyzing both the old and the new version of the package. Note how the traceback is shown adjacent to the code that caused the checker to barf. Similarly, see: http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-06/comparative-re… where cpychecker exceeded one of its builtin limits and only partially analyzed the function (I probably need to tune the thresholds in cpychecker so it doesn't give up so easily). Dave

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

firehose-devel February 2013