Coverity catches X Window Security Hole

Posted May 3, 2006 4:18 UTC (Wed) by dang (guest, #310)
In reply to: Coverity catches X Window Security Hole by bk
Parent article: Coverity catches X Window Security Hole

The game isn't "find the most obscure bugs" but is rather "find the bugs." If you've got a problem with Coverity, then sift through all of the fixes in linux kernel that come out of Viro's bird tree and see how many of the bugs caught through sparse annotations are obvious to the practiced eye. ( Hint: Viro's comments may help you detect these. ) And think about it. Linux code has more active eyes on it than many open source projects and sparse finds stuff. Is it luck? Would people find this stuff eventually? For some of these, empirically the answer seems to be "no" given how long a few of the bugs have been in the code. And even if someone were to eventually find everything, do you really want to wait? Or do you really think that the tool isn't worthwhile for finding things a hell of a lot sooner? Or spin it this way: Why did Linus invest his time in rolling sparse in the first place? Why does Viro spend time on sparse annotations? Why does mingo invest time writing automated lock checking code? The answer is that for any complex code base, you really need automated code checkers and good regression test suites if you want to find and fix bugs ( and it doesn't matter if the bugs are simple or mind-bendingly complex).

Anyone who brings a tool to the table that can improve bug detection rates has a tool worth praise. And if they bother to run it against tons of open source code and feed back to the developers, then they deserve praise for that as well.

Or put it this way: Coverity just provided X users a very valuable service free of charge. Whether they then market the effort has no bearing on the correct response from X users, which should be "thank you."

Rapid development -> new bugs all the time

Posted May 3, 2006 4:57 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

Linux (the kernel) is undergoing rapid change, and has large numbers of developers. This is a recipe for introducing new bugs at a rapid rate, both because you can expect a certain number of bugs to be introduced proportional to the number of new lines of code, and because it's a large, complex piece of software with many constraints that developers must keep in mind.

To get code near-bug-free, you have to stop changing anything about it other than the bugs, and even then you'll introduce some fraction of new bugs per bug fix.

Coverity catches X Window Security Hole

Posted May 3, 2006 14:10 UTC (Wed) by kleptog (subscriber, #1183) [Link]

Coverity is a nice tool, it indeed picks up all sorts of logic errors. Unfortunatly, it's not the brightest. Nearly two-thirds of the "issues" it found in PostgreSQL are false positives. But it's this low-hanging stuff thats nice to have an automated tool to check for because no human will see it.

The other bonus is that if your code is confusing enough to confuse coverity, it probably needs a rewrite anyway :)