qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Can we make better use of Coverity?


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Can we make better use of Coverity?
Date: Wed, 21 Jan 2015 15:19:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0


On 21/01/2015 13:47, Markus Armbruster wrote:
> I also use Coverity locally (requires a license) with a derived model
> for GLib to increase scanning power.  Since last July, the number of
> defects I get that way has increased from ~400 to ~700.  Not quite as
> bad as it sounds, because ~100 of the new ones are DEADCODE.  Still, it
> suggests we haven't made much progress in reducing the number of defects
> to a manageable level.

While I agree that the current frequency of scans is too low, things are
not too bad.  When I do run a scan, I get 10-20 issues.  This is a
volume that I can triage, and I can also (depending on the component)
send the most egregious out to the maintainer or the author of the
offending patch.  It takes me between an hour and two.

There are "only" 221 outstanding defects on Coverity scan, most of which
actually have never been triaged.  This means that maintainers are good
at fixing bugs.  In fact, about 120 of these 221 defects are split
between the "9p", "bt", "disas", "other", "slirp" and "user" components
(i.e. the worst components + the catchall component).  None of the bad
components are in active development; unfortunately, this means that
70-80 defects probably will never be fixed.

Every now and then I refine the components, mostly by looking at defects
in the "other" category.  This had the nice side effect of making
"other" no longer one of the bad components; it's way below the average
of the project.  As a rule of thumb, either we know something is bad, or
we maintain it well.  Again, this is not bad news.

QEMU is also using a GLib model on Coverity Scan, as well as a
QEMU-specific model, which suggests one of the following:

1) your model is not tailored well to QEMU;

2) you are not weeding out false positives.

Between the model, the triaging, and the fixing efforts, our defect rate
has gone down from 0.88 to 0.24 in a year, which I think is pretty good.
 (We could probably it down to 0.15, it's hard to go below that).

> Some of the new defects are avoidable.  For instance, we've added 16
> MISSING_BREAK.  Probably just missing /* fall through */, but we can't
> be sure without examining each case.  Patch review fail.

Or just that we do not care.  Missing /* fall through */ should either
be flagged by the compiler, or treated as a bonus.  Detecting missing
fall through comments is a waste of reviewer brain bandwidth.

> At the other end of the spectrum, I see 36 new UNINIT defects.
> 
> I think we should scan much more regularly.  Once a week, full auto?
> 
> I further think we should send the e-mail report to the list, to have
> more eyes on it.
> 
> Opinions?
> 
> 
> [*] https://scan.coverity.com/projects/378
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]