Finding Bugs Is Easy

daveho writes "My advisor and I are working on a tool to automatically find bugs in Java programs. One of the interesting results of our work is that we've found hundreds of real bugs in production code using extremely simple techniques. We believe that automated tools, if used more widely, could prevent a lot of bugs from making it in to production systems."

Comments

Looks really kewl.

[DeadSea]

I just downloaded this and started playing around with it on my Java utilities.

At first I was frustrated that it needs a jar file. On my hard drive my code is just sitting in directories. So I made a jar file out of my code just for this program.

Then I was frustrated that the GUI wouldn't show me the source, but then I realized that I had compiled without debugging information in my classes (no line numbers and such). I recompiled and remade the jar file and it started showing me the source.

Most of the errors that it finds in my stuff aren't really errors. I get a lot of complaint about "should be declared package" when package is the default and I don't specify a modifier. I also get errors about ignored exceptions for things like this:
} catch (IOException x){
// This can't happen.
// The input and output streams were constructed
// on memory structures that don't actually use IO.
}

I think it may have found a few bugs though. Its complaining about at least one thing not being threadsafe. Also complaining about an inner class being static when it probably shouldn't be.

Now I want an Ant task for this so that I can make sure it runs on my code every time I compile. It is sort of like extended compiler warnings. Pretty helpful.

Re:Looks really kewl.

[addaon]

Why don't you just write the exception

} catch(IOException x) {
assert(false);
}

I'm sure that would make the error go away.

Re:Looks really kewl.

[DeadSea]

That would do it. How about this one?

Uninitialized read of labels in constructor:
if (labels == null){
// setlocale inits labels
setLocale(Locale.getDefault());
}

Its complaining because I'm comparing it to null? I think its a bug in the analysis.

Of course, it would be nice if there were a document that would tell you how to manipulate your code to hide things that you have determined not to be errors from the analyzer. Maybe a list of errors that you have already looked at. Possibly comments you can put in your code.

Re:Looks really kewl.

[splattertrousers]

True, it might be a bug in the analysis, but checking for nulls is not a great practice. Try using the "null object" pattern. Mark Grand describes it thusly:

The Null Object pattern provides an alternative to using null to indicate the absence of an object to delegate an operation to. Using null to indicate the absence of such an object requires a test for null before each call to the other object's methods. Instead of using null, the Null Object pattern uses a reference to an object that doesn't do anything.

The null instance of whatever class your labels variable is could do the locale stuff. (Or maybe it wouldn't work in your case; it's hard to say without the context.)

Bugs in Java code? Inconceivable!

[wowbagger]

Bugs in Java code? Inconceivable!

I thought it was impossible to write bugs in Java - nature's most perfect language! After all, all the Java bigo^H^H^H^Hzealot^H^H^H^H^H^Hexperts have always said that all software problems would vanish if we would just use their perfect language.

(/me removes tongue from cheek)

I just hope that the myriad and varied Java bigots out there will take this to heed: No language can prevent you from making mistakes.

(NOTE: I most emphatically do NOT assert that a language cannot make certain classes of errors more difficult to make!)

(NOTE 2: I also do not assert that all people who use Java, or promote the use of Java are bigots.)

There is no substitute for experience, careful design, and methodical testing.

Reading UGH

[Henry V .009]

I'm reading the UNIX haters guide that got posted recently, and I just wanted to post this:

There are two schools of debugging thought. One is the "debugger as physician" school, which was popularized in early ITS and Lisp systems. In these environments, the debugger is always present in the running program and when the program crashes, the debugger/physician can diagnose the problem and make the program well again.

Unix follows the older "debugging as autopsy" model. In Unix, a broken program dies, leaving a core file, that is like a dead body in more ways than one. A Unix debugger then comes along and determines the cause of death. Interestingly enough, Unix programs tend to die from curable diseases, accidents, and negligence, just as people do.

Re:Reading UGH

[Anonymous Coward]

Your comment didn't make any sence to me until I reallized you are talking about C not UNIX.

The obvious solution...

[Lendrick]

Please note that FindBugs is alpha-quality software. You may find bugs in it, and the features and source code may change significantly in future releases.

...is to run it on itself.

Re:...and?

[michaelggreer]

Javac and Jikes will tell you where it can't compile. This is higher level stuff like "such-and-such should be final" and "you have implemented equals but not hashcode." Code will run, and probably run fine, with these, but they may lead to subtle bugs difficult to track down. Compile-time or formatting bugs are easy to find. Bugs that express themselves in non-obvious ways are what we need more tools for.

In answer to another post, of course good design and good coding are best. This tool does not seek to replace thought, but push us towards proper coding

FindBugs?

[Copperhead]

What kind of name is "FindBugs"? What self-respecting Open Source project would ever name itself after what it actually does? That's so wrong!

They need to pick a name like "||gazm", "JizMop", or "Mozilla" like all the other cool OS projects. I'm sure they'll learn their lesson soon.

Re:FindBugs?

[pmz]

"||gazm"

What a perfect name for a logic-based language or boolean calculator!

Re:FindBugs?

[Ratbert42]

Go with the crowd and just name it Firebird.

History, repeat thyself.

[pmz]

Why not call it "Lint"?

Automated tools like lint are an invaluable part of any software project and should be used at various points in a project's lifecycle. However, the bugs they find tend to be shallow (typecast problems, immediate memory violations, etc.). This is a certain improvement in software quality, but even Java programs can have side-effects from class to class that twist the mind of even the best programmer.

"Finding bugs is easy" makes sense in the context of my backyard but definitely not in programming.

Re:History, repeat thyself.

[crisco]

Speaking of, wasn't there some research posted to /. a few months back that indicated logic errors on the part of the programmer often occured around the smaller errors that programs like this one and lint often catch?

Been there, done that

[Tal Cohen]

While working in IBM Research, we were developing a tool to do just that; I do believe it was significantly richer than this one. The first versions were aimed specifically at J2EE, and searched for really 'high-level' bugs -- anything from bad patterns to violations of the J2EE spec. The initial results of this effort are already included in WebSphere Studio Application Developer 5.0, as part of the Verifiers. More powerful versions will appear in future releases of WSAD.

Re:Been there, done that

[YetAnotherAnonymousC]

IIRC, Oracle also has a tool like this. I think it is called "Code Coach"

Jlint

[mmynsted]

OK.

Why not contribute to the existing, GPL, OpenSource, Java Lint? Why start a new project?

http://artho.com/jlint/

--MM

The real value

[Dr. Bent]

The real value of tools like this is that they act as a sort of Instant Code Review. Just as you can use unit tests to quickly verify the (partial) correctness of your system, you can use tools like this to quickly find bad code so that it can be corrected before it causes more problems. Obviously, just like unit tests are not a complete replacement for QA, this is not a complete replacement for code reviews, but every little but helps.

And although it would be useful everywhere, I would think that a tool like this would fit nicely into an extreme programming shop, where the developers are already used to using automated tools on thier code.

Re:The real value

[Dr. Bent]

You obviously have not used _this_ tool on anything.

I was easily able to it up and running to test a 1000 class project that I've been working on for about two years now. It took all of 5 minutes from the time I read the article on slashdot to the point where I was fixing bugs that I had missed in two years of constant debugging, testing and refactoring. No scripts, no regular expressions, just point at the .jar and go.

Now, granted, they were some fairly simplistic bugs, and it's questionable whether or not they would have ever floated to the surface as an actual bug report. But they would still be in the code now if it wasn't for this tool.

Something else worth a look

[JediTrainer]

Another great tool that deserves a look (besides those already mentioned) is PMD. I use PMD at work to find all sorts of cruft that can be cleaned out of older Java sources. It can be run inside your favourite IDE (to highlight the offending lines) or as an ANT task (generating a report in XML or HTML). Generally I've found it to be a great help, and the coders have been very responsive to my (many) feature suggestions and bug tickets. Most of the things it's found have been general cleanups (ie unused variables or imports), but it also helped find a number of bugs in our code too.

Suggestions to daveho

[jtheory]

I know it's expanding quickly, but the main thing the FindBugs homepage is missing is a list of the errors that FindBugs identifies.

I got a few hints from the screenshots and changelist... but I need more!

* infrastructure for doing dataflow analysis
* tracking of locks for inconsistent synchronization detector
* a few general cleanup fixes in the screenshot

The first 2 especially sound interesting... but not quite enough for me to download a 0.5 version release and slog through the source code.

Halting

[Jason1729]

How did you solve the halting problem? Or does it not check for potential infinite loops?

Jason
ProfQuotes

Re:Halting

[blancolioni]

Checking for infinite loops is not some magical process that brings Turing's ghost down to blow your computer up. All the halting problem shows is that it's impossible to do in general. The specific is a different matter.

Your statement is unnecessarily negative, unhelpful, and a bit silly.

Initial values of variables

[fforw]

Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen.

wrong. The JavaTM Virtual Machine Specification - Second Edition says the following :

2.5.1 Initial Values of Variables

Every variable in a program must have a value before it is used:

• Each class variable, instance variable, and array component is initialized with a default value when it is created:
• For type byte, the default value is zero, that is, the value of (byte)0.
• For type short, the default value is zero, that is, the value of (short)0.
• For type int, the default value is zero, that is, 0.
• For type long, the default value is zero, that is, 0L.
• For type float, the default value is positive zero, that is, 0.0f.
• For type double, the default value is positive zero, that is, 0.0.
• For type char, the default value is the null character, that is, '\u0000'.
• For type boolean, the default value is false.
• For all reference types (2.4.6), the default value is null (2.3).
• Each method parameter (2.5) is initialized to the corresponding argument value provided by the invoker of the method.
• Each constructor parameter (2.5) is initialized to the corresponding argument value provided by an object creation expression or explicit constructor invocation.
• An exception-handler parameter (2.16.2) is initialized to the thrown object representing the exception (2.16.3).
• A local variable must be explicitly given a value, by either initialization or assignment, before it is used.

Bank analogy not flawed

[CompVisGuy]

Imagine that your de-stabilised browser submits a 'random' but 'valid' (under the rules of the bank's error checking code) -- for example you say 'pay the cable co. $40' but your browser transmits 'pay the cable co. $400'.

I don't know which side of the autopsy/physician debugging argument I'd sit on. I quite like Matlab's approach (which I believe is similar to Lisp's), in that you can choose to enter debug mode when an error occurs, and you can then interactively probe you code to find out why it ended up in that state. This is particularly useful when you have (as I do) numerically-intensive code that might take several days to complete running -- you don't want to get to 3.9 days into a 4 day job and find out there was a bug in the very last command your code was to run without being able to figure out exactly why the error occurred -- the write-run-debug cycle would be very long indeed!

So, I can see the benefits of both approaches. I guess having a choice is important, and knowing when to opt for which flavour of error handling.