[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Coverity scan successes
From: |
Paolo Bonzini |
Subject: |
[Qemu-devel] Coverity scan successes |
Date: |
Fri, 14 Mar 2014 13:20:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
Hi all,
I'm happy to announce that the number of outstanding Coverity-reported
defects in QEMU is now down to 0.33 per 1000 lines of code. This is
half the average defect density for open source project (0.69) and also
lower than the average defect density for projects in the 500k-1M SLOC
range (0.44).
3 months ago the ratio was 0.88. Since then it has gone down steadily
thanks to the effort of those who triaged the Coverity reports
(including a couple of people who as far as I know have no other
relationship with the community, and Peter who also reviewed other
people's findings), and those who fixed the bugs (again Peter, and Markus).
Of course, the defect density varies across subsystems:
ratio # defects
SLIRP 2.86 20
9pfs/virtio-9p 1.69 16
Bluetooth 1.31 6
NBD 1.31 2
User-mode emulation 0.84 25
Block layer 0.66 25
Migration 0.61 2
PCI 0.54 6
SCSI 0.59 8
Networking 0.48 11
ARM device models 0.34 13
USB 0.24 5
(Anything else) 0.23 149
TCG 0.09 1
Monitor 0.08 2
Tracing 0.00 0
Of course these data have to be taken with a grain of salt, as subsystem
boundaries are not necessarily sharp, but I think that the overall
picture is pretty good. Of the 4 top "offenders", three actually match
little-used (and unfortunately also little-maintained) functionality.
And there are several subsystems that could easily go down to zero defects.
You may have noticed that I've sent a couple of nag mails to people who
had their code flagged by Coverity. Because of the nature of QEMU,
sometimes people simply cannot know what you intended to do without
accurate documentation or datasheets for the hardware you're emulating.
What may look like a simple off-by-one error might actually hide an
incorrect interpretation of the datasheet. For this reason, it is
important for authors of the code to fix things when they are reported
to them.
There is of course still work to do. There are 100 actual bugs still to
be fixed, most of them insignificant or minor but also some memory
corruptions; almost 200 issues are still pending triage.
Another interesting thing to do is to write models
(https://scan.coverity.com/models) for functions that Coverity
consistently reports false positives about. address_space_rw is a
particularly central one.
If you are interested in helping out, you can contact me offlist.
Paolo
- [Qemu-devel] Coverity scan successes,
Paolo Bonzini <=