Null dereference analysis in practice

Authors:
Nathaniel Ayewah;William Pugh
Affiliations:
University of Maryland, College Park, MD, USA;University of Maryland, College Park, MD, USA
Venue:
Proceedings of the 9th ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering
Year:
2010

Citing 8
Cited 0

Extended static checking for Java

PLDI '02 Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation
Declaring and checking non-null types in an object-oriented language

OOPSLA '03 Proceedings of the 18th annual ACM SIGPLAN conference on Object-oriented programing, systems, languages, and applications
Preliminary design of JML: a behavioral interface specification language for java

ACM SIGSOFT Software Engineering Notes
Tracking defect warnings across versions

Proceedings of the 2006 international workshop on Mining software repositories
Specifying and verifying software

Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering
Practical pluggable types for java

ISSTA '08 Proceedings of the 2008 international symposium on Software testing and analysis
Accurate Interprocedural Null-Dereference Analysis for Java

ICSE '09 Proceedings of the 31st International Conference on Software Engineering
The Google FindBugs fixit

Proceedings of the 19th international symposium on Software testing and analysis

Quantified Score

Hi-index	0.00

Visualization

Abstract

Many analysis techniques have been proposed to determine when a potentially null value may be dereferenced. But we have observed in practice that not every potential null dereference is a "bug" that developers want to fix. In this paper we discuss some of the challenges of using a null dereference analysis in practice, and reasons why developers may not feel it necessary to change code to prevent ever possible null dereference. We revisit previous work on XYLEM, an interprocedural null dereference analysis for Java, and discuss the challenge of comparing the results of different static analysis tools. We also report experimental results for XYLEM, Coverity Prevent, Fortify SCA, Eclipse and FindBugs, and observe that the different tools tradeoff the need to flag all potential null dereferences with the need to minimize the number of cases that are implausible in practice. We conclude by discussing whether it would be useful to extend the Java type system to distinguish between nullable and nonnull types, and prohibit unchecked dereferences of nullable types.