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 >
