The first year of Coverity Linux kernel scans

[khc]

http://codemonkey.org.uk/2014/08/13/year-coverity-linux-kernel-scans/

[lelf]

Examples of the actual errors found would be far more interesting.

[justinmk → lelf]

If it's anything like the Neovim coverity report, it's probably not particularly interesting. But it is extremely helpful, and it's impressive what static analysis can find in a legacy C codebase. Here's the Neovim clang analysis:

http://neovim.org/doc/build-reports/clang/

Click on any of the "View Report" links to see a line-by-line step-through of each suspected bug.

(Coverity doesn't allow public access to reports AFAIK, so can't link to it.)

[seren → justinmk]

Sorry to highjack the thread, but if I want to fix some neovim Coverity issues, where should I register / who should I ask ? I have already had a look to your waffle but it was not crystal clear. Just creating a Coverity account will allow me to access the report ? Thanks in advance.

[davis → seren]

Login then go to https://scan.coverity.com/projects/2227 and request access. If you want to fix Coverity issues, request access at the Contributor level.

For more info on Coverity fixes and conventions, check out the Wiki page: https://github.com/neovim/neovim/wiki/Contributing#coverity

[pgeorgi → lelf]

We recently started using Coverity Scan for coreboot. So far I mostly took on the low hanging fruits, relevant commits can be found through http://review.coreboot.org/#/q/message:%22Coverity+Scan%22

We'll soon start using clang's scan-build systematically, too.

[binarymax → lelf]

Clicking into some other posts in the same topic, there are a couple examples:

    if (condition)
        bar();
    else
        bar();

And

    switch (foo) {
        case 0: bar();
                ;;
        case 1: misc();
                break;
    }

[sounds → lelf]

I figured the last sentence of the post, specifically "there are a few interesting cases," would mean he will post some specific examples next time.

Crossing my fingers.

[gwern]

Has the use of Coverity on the kernel lead to any improvements in Coverity itself, aside from the mentioned email feature request?

[cperciva → gwern]

I don't know about linux, but I've heard that they made lots of improvements in Coverity after running it against FreeBSD (we were one of the first large codebases they inspected); most notably in false-positive reduction, since it provided them with an opportunity to see lots of idioms which are correct but potentially confusing to a static analysis tool.

[ddp → cperciva]

Is Coverity integrated into the FreeBSD build system? A quick search on FreeBSD.org shows some activity back in 2006 but not much mention of it since. I'd be interested in seeing the results in /usr/src/sys/netinet6 and netipsec. Is there a reason why the scan results require committer access?

[npsimons → ddp]

I would be surprised if Coverity was integrated into any open source project's build system. All due respect to the Coverity folks, and Coverity is a great tool, it's still closed source. To be honest, I suspect the Coverity folks are getting as much (or more) out of running their tool against these projects as the projects are. I would like to see the scan results opened up too, which would be in keeping with the open nature of these projects. I'm willing to bet there's paranoia about competition duplicating features from Coverity, so that would explain why they limit it to comitter access (and required signing an NDA last I checked).

EDIT: I stand corrected - Python has integrated Coverity into their builds: https://docs.python.org/devguide/coverity.html

It still bothers me that the scan reports aren't open; it feels antithetical to the nature and spirit of open source software.

[cperciva → ddp]

Is there a reason why the scan results require committer access?

Coverity says that only "project members" can get access to the full bug reports. IIRC there's also a rule about not posting verbatim Coverity reports anywhere publicly visible.

I assume this is "stop the competition from seeing what we're doing", but I've never asked.

[khc → cperciva]

I think the bigger problem is that the issues are potentially security issues.