[libvirt] [PATCH 0/7] Address some Coverity found issues

John Ferlan jferlan at redhat.com
Fri Jul 3 13:36:14 UTC 2015



On 07/02/2015 05:30 AM, Michal Privoznik wrote:
> On 01.07.2015 16:03, John Ferlan wrote:
>>
> 
> I'm picking a random Coverity thread to express my latest thoughts on
> this. I'm not trying to say the problems I'm raising are necessarily
> introduced here in this patch set.
> 
> We've seen quite a lot of false positives lately. I'm not familiar with
> coverity, but does it have a suppress file, something like valgrind has?
> In valrgind, one can enumerate stacktraces that would be reported, but
> has been investigated by a developer and therefore are known to be okay.
> If coverity would have something like that I think should utilize it.
> 
> We've poisoned our code with sa_assert()-s, dummy coverity comments,
> etc. If we can keep our code clean, that'd be nice. I guess I'm okay
> with having the coverity suppress file in the repo - we have the
> valgrind one already.

Not sure how a Coverity suppress file works, but if I have some cycles
I'll look into it. However, if it's susceptible to code motion, then it
may not be worth it...  The last time I looked (almost 2 years ago) at
the valgrind suppress file it had some stale chunks, but it also had a
decent way to "ignore" certain traces.

In any case, I'll look into removing existing sa_assert()'s... As a
test, I removed the definition and reran a build to find areas that
currently "require" it. I think of the 15 or so "issues", perhaps 1 or 2
could go away with some refactoring.

> 
> Oh, and for false positives maybe we should file a bug report against
> coverity (if possible).
>

That's generally the more difficult part especially when it comes to
replicating the build environment (including .gnulib) in a "small
module" as any good developer would ask for when someone claims your
product has a defect.  Also as I pointed out before - those aren't
necessarily Coverity defects - it's pointing out valid concerns which
take human intervention to determine whether they are a problem or not.

John





More information about the libvir-list mailing list