We found 10,000 bugs in various open source projects.

In order to popularize the static analysis methodology in general and the PVS-Studio analyzer in particular, we regularly check various open source projects. The bugs found in them perfectly demonstrate that no one is immune from typos, inattention and other mistakes. It is no one, and we find confirmation of this in such projects as Microsoft Code Contracts, Qt, Linux kernel, CryEngine, VirtualBox, LibreOffice, Firefox, Boost, Tor, and so on. At the moment, we have tested 262 projects. And so it happened, we found and discharged 10,000 bugs into the database.



As a rule, when we find a sufficient number of errors in a project, we write about this article. A list of these articles can be found here . If there are only a few errors, we simply report them to the project developers and continue to do other things.



Of course, 10,000 errors on 262 projects is not much. It turns out that on average we found 38 errors in the project. It is worth noting that in fact this number does not mean anything. The size and quality of projects is very different. For example, somewhere we find only one mistake , and somewhere there are hundreds of them.



It is also important to note that in order to popularize static analysis and PVS-Studio, we do not need to find as many errors as possible. We need to find the number of errors sufficient for writing the article. Therefore, we always offer project authors to check their code more thoroughly. Anyway, it is good to use one-time checks of the project to demonstrate the capabilities of the analyzer, but there is little benefit from them. The whole point of static analysis is its regular use. Then many errors can be detected even at the stage of writing the code, and not after 50 hours of debugging or after user complaints.

')

It's time to give a link to the collected errors:



Base of errors found in open source projects



This base can serve as a unique material for reflection on the development of coding standards, writing articles on programming rules, and help in other studies related to improving the reliability of software. Example: " The Last Line Effect ". We wish interesting research.