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

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?

Re:Reading UGH

[Anonymous Coward]

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

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.

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.

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.