focus



IEEE SotwarE

Published by the IEEE Computer Society



software development tools

Using Static Analysisto Find Bugs

Nathaniel Ayewah and William Pugh,

University of Maryland

David Hovemeyer,

York College of Pennsylvania

J. David Morgenthaler and John Penix,

Google

FindBugs, an opensource static-analysistool for Java,evaluates what kindsof defects can beeffectively detected with relativelysimple techniques.

otware quality is important, but oten imperect in practice. We can use manytechniques to try to improve quality, including testing, code review, and or-mal specication. Static-analysis tools evaluate sotware in the abstract, with-out running the sotware or considering a specic input. Rather than tryingto prove that the code ullls its specication, such tools look or violations o reason-able or recommended programming practice. Thus, they look or places in which codemight dereerence a null pointer or overfow an array. Static-analysis tools might also

fag an issue such as a comparison that can’t pos-sibly be true. Although the comparison won’t causea ailure or exception, its existence suggests that itmight have resulted rom a coding error, leading toincorrect program behavior.Some tools also fag or enorce programmingstyle issues, such as naming conventions or the useo curly braces in conditionals and looping struc-tures. The lint program or C programs

is gener-ally considered the rst widely used static-analysistool or deect detection, although by today’s stan-dards it’s rather limited. Researchers have donesignicant work in the area over the past decade,driven substantially by concerns over deects thatlead to security vulnerabilities, such as buer over-fows, ormat string vulnerabilities, SQL injection,and cross-site scripting. A vibrant commercial in-dustry has developed around advanced (and expen-sive) static-analysis tools,

2,3

and several companieshave their own proprietary in-house tools, such asMicrosot’s PREx.

Many commercial tools aresophisticated, using deep analysis techniques. Somecan use or depend on annotations that describe in-variants and other intended sotware propertiesthat tools can’t easily iner, such as the intended re-lationship between unction parameters.FindBugs is an example o a static-analysis toolthat looks or coding deects.

5–7

The FindBugsproject began as an observation, developed into anexperiment, and snowballed into a widely used toolwith more than hal a million downloads world-wide. The observation that started it all was thatsome Java programs contained blatant mistakesthat were detectable with airly trivial analysistechniques. Initial experiments showed that even“production quality” sotware contained such mis-takes and that even experienced developers madethem. FindBugs has grown, paying careul atten-tion to mistakes that occur in practice and to thetechniques and eatures needed to eectively incor-porate it into production sotware development.Here, we review the types o issues FindBugsidenties, discuss the techniques it uses, and lookat some experiences using FindBugs on Sun’s JavaDevelopment Kit (JDK) and Google’s Java codebase.

Authorized licensed use limited to: IEEE Xplore. Downloaded on March 2, 2009 at 14:41 from IEEE Xplore. Restrictions apply.



September/October 2008

IEEE SotwarE



FindBugs in practice

In its current orm, FindBugs recognizes more than300 programming mistakes and dubious coding id-ioms that it can identiy using simple analysis tech-niques. FindBugs also uses more sophisticated anal-ysis techniques, devised to help eectively identiycertain issues—such as dereerencing o null point-ers—that occur requently enough to warrant theirdevelopment. Unlike some other tools designed toprovide security guarantees, FindBugs doesn’t tryto identiy all deects in a particular category orprove that sotware doesn’t contain a particular de-ect. Rather, it’s designed to eectively identiy low-hanging ruit—to cheaply detect deects we believedevelopers will want to review and remedy.Many developers use FindBugs ad hoc, and agrowing number o projects and companies areintegrating it into their standard build and testingsystems. Google has incorporated FindBugs into itsstandard testing and code-review process and hasxed more than 1,000 issues in its internal codebase that FindBugs has identied.

Defects in real code

To appreciate static analysis or deect detectionin general, and FindBugs in particular, it helps tobe amiliar with some sample deects ound in realcode. Let’s look at some examples rom Sun’s JDK1.6.0 implementation, which also are representativeo code seen elsewhere.One unexpectedly common deect is the in-nite recursive loop—that is, a unction that alwaysreturns the result o invoking itsel. We originallyextended FindBugs to look or this deect becausesome reshman at the University o Marylandhad trouble understanding how Java constructorsworked. When we ran it against build 13 o Sun’s JDK 1.6, we ound ve innite recursive loops,including

public String foundType() {return this.foundType();}

This code should have been a getter method orthe eld

foundType

, but the extra parenthesis meansit always recursively calls itsel until the stack over-fows. Various mistakes lead to innite recursiveloops, but the same simple techniques can detectthem all. Google has ound and xed more than 70innite recursive loops in their code base, and theyoccur surprisingly requently in other code baseswe’ve examined.Another common bug pattern is when sotwareinvokes a method but ignores its return value, de-spite the act that doing so makes no sense. An ex-ample is the statement

s.toLowerCase()

, where

is a

String

.Because

Strings

in Java are immutable, the

toLowerCase()

method has no eect on the String it’s invoked on,but rather returns a new

String

. The developer prob-ably intended to write

s = s.toLowerCase()

. Another ex-ample is when a developer creates an exception butorgets to throw it:

try { ... }catch (IOException e) {new SAXException(....);}

FindBugs uses an intraprocedural datafow anal-ysis to identiy places in which the code could dere-erence a null pointer.

5,7

Although developers mightneed to examine dozens o lines to understand somedeects reported by FindBugs, most can be under-stood by examining only a ew lines o code. Onecommon case is using the wrong relational or Bool-ean operation, as in a test to see whether

(name != null|| name.length > 0)

. Java evaluates the

and

opera-tors using short-circuit evaluation: the right-handside is evaluated only i needed in order to determinethe expression’s value. In this case, Java will evalu-ate the expression

name.length

only when

name

is null,leading to a null pointer exception. The code wouldbe correct i it had used

rather than

. FindBugsalso identies situations in which the code checksa value or null in some places and unconditionallydereerences it in others. The ollowing code, or ex-ample, checks the variable

to see i it’s null, but i it is null, the next statement will always deerence it,resulting in a null pointer exception:

if (g != null)paintScrollBars(g,colors);g.dispose();

FindBugs also perorms an intraprocedural typeanalysis that takes into account inormation rom

instanceof

tests and nds errors such as checked caststhat always throw a class cast exception. It alsonds places in which two objects guaranteed to beo unrelated types are compared or equality (orexample, where a

StringBuffer

is compared to a

String

,or the bug Figure 1 shows).Many other bug patterns exist, some coveringobscure aspects o the Java APIs and languages. Aparticular pattern might nd only one issue in sev-eral million lines o code, but collectively these

nda signicant number o issues. Examples includechecking whether a double value is equal to

Double.NaN

(nothing is equal to

Double.NaN

, not even

Double.NaN

)

FindBugsdoesn’t tryto identifyall defectsin a particularcategory.

Authorized licensed use limited to: IEEE Xplore. Downloaded on March 2, 2009 at 14:41 from IEEE Xplore. Restrictions apply.



IEEE SotwarE

www.computer.org/software

or perorming a bit shit o a 32-bit

int

value by aconstant value greater than 31.

wh indBugs desn’ fnd

FindBugs doesn’t look or or report numerous po-tential deects that more powerul tools report.

2–4

We designed it this way or two reasons: to keepthe analysis relatively simple and to avoid generat-ing too many warnings that don’t correspond totrue deects.One such case is nding null pointer dereerencesthat occur only i a particular path through the pro-gram is executed. Reasoning reported such an issuein Apache Tomcat 4.1.24.

Reasoning warns that i the body o the rst

statement isn’t executed butthe body o the second

statement is executed, thena null pointer exception will occur:

HttpServletResponse hres = null;if (sres instanceof HttpServletResponse)hres = (HttpServletResponse) sres; // Check to see if availableif (!(...).getAvailable()) {hres.sendError(...)

The problem is that the analysis doesn’t knowwhether that path is easible. Perhaps the conditionin the second statement can be true only i the con-dition in the rst statement is true. In some cases,the conditions might be closely related and somesimple theorem proving can show whether the pathis easible or ineasible. But showing that a particu-lar path is easible can be much harder, and is ingeneral undecidable.Rather than worry about whether particularpaths are easible, FindBugs looks or branches orstatements that, i executed, guarantee that a nullpointer exception will occur. We’ve ound that al-most all null pointer issues we report are either realbugs or inconsistent code with branches or state-ments that can’t be executed. Code that is merelyinconsistent might not be changed i it’s alreadyused in production, but generally would be con-sidered unacceptable in new code i ound duringcode review.We also haven’t pursued checks or array indi-ces that are out o bounds. Detecting such errors re-quires tracking relations between various variables(or instance, is

less than the length o

), and canbecome arbitrarily complicated. Some simple tech-niques might accurately report some obvious bugs,but we haven’t yet investigated this.

FindBugs nuts and bolts

FindBugs has a plug-in architecture in which de-tectors can be dened, each o which might reportseveral dierent bug patterns. Rather than use apattern language to describe bugs (as PMD

andMetal

do), FindBugs detectors are simply writ-ten in Java using various techniques. Many simpledetectors use a visitor pattern over the class lesor method byte codes. Detectors can access inor-mation about types, constant values, and specialfags, as well as values stored on the stack or in localvariables.Detectors can also traverse the control-fowgraph, using the results o data-fow analysis such astype inormation, constant values, and nullness. Thedata-fow algorithms all generally use inormationrom conditional tests, so that the analysis results in-corporate inormation rom

instanceof

and null tests.FindBugs doesn’t perorm interprocedural con-text-sensitive analysis. However, many detectorsuse global inormation, such as subtype relation-ships and elds accessed across the entire applica-tion. A ew detectors use interprocedural summaryinormation, such as which method parameters arealways dereerenced.FindBugs groups each bug pattern into a cat-egory (such as correctness, bad practice, peror-mance, and internationalization) and assigns eachbug pattern report either high, medium, or lowpriority. FindBugs determines priorities via heuris-tics unique to each detector or pattern that aren’tnecessarily comparable across bug patterns. In nor-mal operation, FindBugs doesn’t report low-prioritywarnings.The most important aspect o the FindBugsproject is perhaps how we develop new bug detec-tors: we start with real bugs and develop the sim-plest possible technique that eectively nds suchbugs. This approach oten lets us go rom nding aparticular instance o a bug to implementing a de-

Figure 1. The FindBugsSwing GUI. Theinterface showsFindBugs reviewinga bug in Sun’s JavaDevelopment Kit.

Authorized licensed use limited to: IEEE Xplore. Downloaded on March 2, 2009 at 14:41 from IEEE Xplore. Restrictions apply.