From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDwvx-00047j-ET for qemu-devel@nongnu.org; Wed, 21 Jan 2015 10:11:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDwvu-0000OP-4l for qemu-devel@nongnu.org; Wed, 21 Jan 2015 10:11:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDwvt-0000OF-Sc for qemu-devel@nongnu.org; Wed, 21 Jan 2015 10:11:02 -0500 Message-ID: <54BFC17D.2060501@redhat.com> Date: Wed, 21 Jan 2015 16:10:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <87bnlsl2qt.fsf@blackfin.pond.sub.org> <54BFB577.3080805@redhat.com> <87a91cchbt.fsf@blackfin.pond.sub.org> In-Reply-To: <87a91cchbt.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Can we make better use of Coverity? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org 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. >> 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. >> 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. >>> 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. :) Paolo