Finding more null pointer bugs, but not too many

Abstract

In the summer of 2006, the FindBugs project was challenged to improve the null pointer analysis in FindBugs so that we could find more null pointer bugs. In particular, we were challenged to try to do as well as a publicly available analysis by Reasoning, Inc on version 4.1.24 of Apache Tomcat. Reasoning's report is a result of running their own static analysis tool and using manual auditing to remove false positives. Reasoning reported a total of 9 null pointer warnings in Tomcat 4.1.24, of which only 2 were reported by FindBugs 1.0. While we wanted to improve the analysis in FindBugs, we wanted to retain our current low level of false positives.As of result of the work presented in this paper, FindBugs now reports 4 of the 9 warnings in Tomcat, shows that one of the warnings reported by Reasoning is a false positive, and classifies the remaining 4 as being dependent on the feasibility of a particular path, which cannot be easier ascertained by a local examination of the source code. Moreover, we found 24 additional null pointer bugs in Tomcat that had been missed by Reasoning, and overall doubled the number of null pointer bugs found by FindBugs while improving the quality and significance of reported defects.

Using Static Analysis to Find Bugs

“…5,7 Although developers might need to examine dozens of lines to understand some defects reported by FindBugs, most can be understood by examining only a few lines of code. One common case is using the wrong relational or Boolean operation, as in a test to see whether (name != null || name.length > 0).…”

“…[5][6][7] The FindBugs project began as an observation, developed into an experiment, and snowballed into a widely used tool with more than half a million downloads worldwide. The observation that started it all was that some Java programs contained blatant mistakes that were detectable with fairly trivial analysis techniques.…”

Semantic Foundations and Inference of Non-null Annotations

“…inferring nullness property for blocks of code from the guards. This is notably the case of FindBugs [11,10] and of the work by Male et al [15]. They rely on path-sensitive analysis and the treatment of field initialization is very weak.…”

Report generation for simulation traces with Traviando

“…With the generation of this list of warnings, we attempt to accumulate "lessons learned" experiences such that common errors and pitfalls are detected. The approach is stimulated by the way software development is supported by static code analysis, where a software tool generates a report for a given program code that lists locations in the code base that require further attention based on a set of rules that incorporate knowledge on common pitfalls in programming; see FindBugs as a particular example [7]. In dependability modeling, there is no one (or few) common main stream model notation as it is the case in programming, but there is a common ground for the execution of stochastic DEDS models as a state transition system.…”