Re: [libvirt] Coverity scan

On 12/20/2012 04:24 PM, Eric Blake wrote: > On 12/20/2012 08:25 AM, John Ferlan wrote: >> >> First allow me to introduce myself - I'm John Ferlan a new Red Hat employee (3 weeks). I came from the closed world at HP where for the last 7 years I worked in a group developing/supporting HP's Integrity Virtual Machine software prior to it being outsourced to India this past May. I primarily worked in the CLI/API and daemon space, although I also spent quite a bit of time in the lower virtualization layers which mimicked the Integrity instructions. I am very happy to be in the open world and look forward to contributing. Everyone has to start some where. > > Welcome to libvirt! Based on recent list traffic, there are several > people, not just John, and not just at Red Hat, that are aiming to > provide initial contributions. Be sure to provide your feedback and > questions on the list, and hopefully we can use that to make our hacking > documentation even easier to follow for future newcomers. > > You may want to figure out why your mailer doesn't automatically wrap > long lines. Webmail interfaces (gmail, zimbra) and Microsoft Exchange > tend to be the worst mail agents when it comes to RFC compliance and > lack of knobs to tune for improving the situation, which in turn can > make it harder to read your messages and apply patches you submit. You > may notice that many people on this list use mutt or Thunderbird rather > than web mailers, if only to have better formatted mail, but it's not a > hard pre-requisite (we won't reject a patch just because of how it was > sent, although it might take longer to apply if we have to jump through > hoops to get it extracted from the mail). For mailers that have the > right knobs, turning on format=flowed is one way of sending reasonably > formatted mail [but be aware that Thunderbird has had a rather nasty bug > for several years now where defaulting to format=flowed can result in > botching the whitespace of the quoted portion of a message you are > replying to]. > >> >> My first task here at Red Hat was to triage a Coverity scan executed against libvirt-1.0.0-1.fc19.src.rpm done in late November. There were 285 issues documented. I quickly found that some of the defects found there were already fixed in later submits upstream, so I ran a new Coverity scan last Friday and it came back with 297 issues broken down as follows: >> >> 1 ARRAY_VS_SINGLETON >> 33 BAD_SIZEOF >> 17 CHECKED_RETURN >> 1 CONSTANT_EXPRESSION_RESULT >> 5 COPY_PASTE_ERROR >> 13 DEADCODE >> 46 FORWARD_NULL >> 2 MISSING_RETURN >> 2 NEGATIVE_RETURNS >> 7 NULL_RETURNS >> 1 OVERRUN >> 137 RESOURCE_LEAK >> 18 REVERSE_INULL >> 1 SIGN_EXTENSION >> 3 UNINIT >> 8 UNUSED_VALUE >> 2 USE_AFTER_FREE > > Thanks for doing this. Helping to reduce the false positives and > eliminate the real bugs will make it easier to run Coverity on a > periodic basis and check for recent regressions while the code is still > fresh on our minds. Looking forward to the patches you come up with. > Ran a new scan recently - the number of defects increased slightly (+4 FORWARD_NULL, +2 MISSING_RETURN, and + 1 UNINIT). I worked my way through the entire list and just figured I'd start with an easier group for my first submit attempt. I have a series of relatively easy changes for the "CHECKED_RETURN" condition; however, I was hoping to perhaps get some feedback on two files which had more ramifications from just checking the return status. The first is 'src/phyp/phyp_driver.c'. Neither waitsocket() nor any of the callers check the return status. The implication being if select() fails the code will continue to wait. So is this "desired"? Conversely what are the ramifications of checking status on select() and using virReportSystemError()? Or perhaps some other way to log the failure? For any of the callers, any concerns over checking status return == -1 and jumping to the err label? I guess I'm concerned over making logic/flow changes to some long standing assumption. I've been on the opposite end of debugging one of those.

The second is 'src/rpc/virnetsocket.c'. The Coverity complaint is that the setsockopt() call to set SO_REUSEADDR doesn't check the return status. I think this particular case may be a cut-n-paste type change as the from virNetSocketNewListenTCP(). Unless I'm missing something, does setting the reuse addr on a connect socket do anything? Can it just safely be removed?