Slashdot Mirror

← Back to Stories (view on slashdot.org)

Finding Bugs Is Easy

Posted by timothy on from the roll-the-log-over dept.

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."

4 of 66 comments (clear)

  1. Looks really kewl. by DeadSea · · Score: 4, Interesting
    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.

  2. Reading UGH by Henry+V+.009 · · Score: 4, Interesting
    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.
  3. Jlint by mmynsted · · Score: 4, Interesting

    OK.

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

    http://artho.com/jlint/

    --MM

  4. The real value by Dr.+Bent · · Score: 2, Interesting

    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.