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: Markus Armbruster
Subject: Re: [Qemu-devel] Can we make better use of Coverity?
Date: Wed, 21 Jan 2015 17:05:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> On 21/01/2015 15:57, Markus Armbruster wrote:
>>> QEMU is also using a GLib model on Coverity Scan, as well as a
>>> QEMU-specific model, which suggests one of the following:
>> 
>> What do you mean by "a GLib model"?  scripts/coverity-model.c?
>
> Yes.  It models g_malloc0 in a way that avoids a lot of false positives,
> but still is able to flag leaks.

Understood.  It's hugely better than nothing, but it still can't make
Coverity see many relevant facts like GLib functions returning newly
allocated storage.  For that, you have to throw in a derived model, like
I do.  Unfortunately, the Scan service seems unable to do that.

>>> 2) you are not weeding out false positives.
>> 
>> Guilty as charged.  The proper place to do that is the Scan service,
>> where all of us can profit.
>
> Yup.  So the numbers are off by a couple hundred or so, assuming 20%
> false positive rate.

Yes.  I should've made that clear.

>>> 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).
>> 
>> As I said: "We've put in some effort, and we've gotten some mileage out
>> of it, but I feel we could get more."
>
> Definitely.  But we've gotten much more than "some mileage" IMO.

Conceded.

>>>> 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,
>> 
>> Unfortunately, gcc doesn't.  Relying on tools for this is fine, but
>> requires actual use of said tools.  Which this thread is about :)
>
> Sure.  But even then, MISSING_BREAK is not the #1 reason to have
> Coverity around. :)

MISSING_BREAK is almost always a false positive.  But when it isn't, it
can be anything from harmless bug to security hole.

Regardless, I agree many other Coverity checkers are more valuable.



reply via email to

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