Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Bug

Finding Bugs Is Easy 66

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Finding Bugs Is Easy More

Finding Bugs Is Easy

Comments Filter:

  • So (Score:1)

    by lh0628 ( 517993 )
    Just out of curiosity, what did you use when debugging this program?

    • what did you use when debugging this program?

      The most productive debugging happens in the design phase. Keeping each independent module small, simple, and focused, makes it harder to make a mistake.

  • Looks really kewl. (Score:5, Interesting)

    by DeadSea ( 69598 ) * on Monday April 28, 2003 @01:58PM (#5827175) Homepage Journal
    I just downloaded this and started playing around with it on my Java utilities [ostermiller.org].

    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. (Score:3, Informative)

      by addaon ( 41825 )
      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. (Score:3, Insightful)

        by DeadSea ( 69598 ) *
        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 c

        • 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 [mindspring.com] 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 anythin

        • If it's in a constructor, both you and the compiler should know equally well whether it's initialized. Of course, this being java, it's always initialized to null (unless you've already initialized it to something else of course), so the test is kind of pointless when compared to a C/C++-checker, but being null might still be an error if you didn't intend it, and if you want it to be null, you can initialize it explicitly.

          The fix is of course to remove the check. Then you don't read uninitialized memory.

        • Just a guess, but is it complaining because of a lack of guaranteed initialization?

          Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen. Without explicit initialization to null, some JVM could just give you whatver data was in some register, which is more than likely *not* null. It's good that it's complaining, if that's the complaint.

          • 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 [sun.com] 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
            • In reality, not every JVM follows that part of the spec. I have come across at least one that didn't, and IIRC it was even one of Sun's ones.
              • In reality, not every JVM follows that part of the spec. I have come across at least one that didn't, and IIRC it was even one of Sun's ones.

                well.. As the VM spec says otherwise, it's a bug. Elevating that bug to an exception/restriction makes no sense.

                (Are you sure the variable was not initialized? or was it some Serialization-effect?)

        • The paper explains the rationale for each check. For "read of uninitialized field in constructor", the idea is that since the field has the default value, it makes no sense to read it, so the code is at best useless. In another post I think you said it was a static field, so it looks like you've discovered a bug in FindBugs.
    • } catch (IOException x){
      // This can't happen.
      // The input and output streams were constructed
      // on memory structures that don't actually use IO.
      }

      If it really can't happen, why not this:

      } catch (IOException canNotHappen) {
      throw new RuntimeException( "Exception that cannot happen actually did happen" + canNotHappen );
      }

      That way, if it really does happen, you'll find out about it.

      • That's what I do, except use an InternalError instead. Then you *really* get to know about it ;-)

        I've never understood why if you have an exception that cannot happen anyone would ever want to ignore if it did. It makes no sense! You would want to know if it happened in the noisiest, loudest way! Some plonker will come along and change your code and the exception will then be able to occur.

    • Even though package is the default, declare it anyway - Good practice.

      Other rules of thumb for any programming language

      Use the strictest compiler setting you can, and clean up any errors it finds

      Don't do automatic type casting - heck, things like variants and auto type casting is what helped give VB a bad name in some circles - folks were screaming for strict casting back in VB4, and finally started to get in in VB.NET
    • From page:
    • Presentation slides from Finding Bugs is Easy, invited talk, MASPLAS 2003
    I get error 403 - permission error. I'll look at the other PDF later tonite I hope.
    • - RR

  • Bugs in Java code? Inconceivable! (Score:3, Funny)

    by wowbagger ( 69688 ) * on Monday April 28, 2003 @02:02PM (#5827243) Homepage Journal
    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.
    • Anybody who claims that you can't write a bug in Java has no experience and isn't very creative.
    • Bugs in Java code?

      Yup. While bounded arrays help remove certain classes of bugs, for example, the "null pointer exception" stepped in exactly where "segmentation fault" left.

      The complexity of programming has been pretty constant since FORTRAN was adopted over assembler. "Object-oriented" removed some complexity but added its own, so the net gain is small. Maybe "aspects" will finally save us...maybe not.
      • >>The complexity of programming has been pretty constant since FORTRAN was adopted over assembler

        I don't know... my programs have gotten much simpler since I started programming in Scheme. Except for having to write a lot of my own data structures. But thats no worse than C.

      • The complexity of programming has been pretty constant since FORTRAN was adopted over assembler.

        Man, there is no way I'd buy that. Ever see a copy of K&R sitting next to Stroustrup on the shelf?
    • Bugs in Java code? Inconceivable!

      Now, the Java inventors were Sicilians; and everybody knows that you can't trust Sicilians... so you can't take the language that's before them! But... they would have expected you to know that, so you clearly can't take the language that's in front of you...

      "You think that's good? Wait 'till I get going!" (-:


    • No language can prevent you from making mistakes.
      Assuming that it even existed, you can always make something that realizes a totally different task from the intended - that might be actually beneficial - I could use a teleporter for example. >:->

  • ...you can even order some over the internet! [microsoft.com]

    Okay low blow, but joking aside, what's newsworthy about this? Is there something that sets it apart from run-of-the-mill linters?

  • Reading UGH (Score:5, Interesting)

    by Henry V .009 ( 518000 ) on Monday April 28, 2003 @02:10PM (#5827387) Journal
    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 (Score:2, Insightful)

      by Anonymous Coward
      Your comment didn't make any sence to me until I reallized you are talking about C not UNIX.
    • Bugs that crash a program are relatively easy to find. If, instead, the program continues in a non-determined fashion, the bug turns into a subtle one. Subtle bugs are nastier, hence the emphasis on autopsy. Users prefer crashing bugs too: I would rather my web-browser crash outright than submit something random to my bank.
      • Really? Why is it not the bank's responsibility to make sure it's getting valid input and not "something random"? If I attempt to transfer a random string of text from one account to another, I don't suppose it's very likely to be all numbers and to also be a valid amount. If my bank is that stupid, I'll find another bank.
        • Forget the bank analogy then. It's still true.

          Would you rather have your text editor hit a bug and write random garbage over your term paper, or would you rather it just crash?
          • I'll take closing and re-opening a file over having to restart the application. I'm just lazy that way.
            • I'll take closing and re-opening a file over having to restart the application.

              Huh? What makes you think that's an option, and how would it make any sense?

              It writes corrupted data. You are not aware of this. You close the file. You open it again, maybe a few days later. You find out your hard work is hopelessly lost.

              vs.

              It crashes. You are immediately aware of this. You reopen the app and the file. Maybe you've lost back to the last time you saved, at most.
        • 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
  • Many languages have tools such as this. Lint comes to mind, and GCC tells you where it gags if it can't compile a piece of code for some reason.

    • Re:...and? (Score:5, Informative)

      by michaelggreer ( 612022 ) on Monday April 28, 2003 @02:23PM (#5827586)

      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

  • The obvious solution... (Score:4, Funny)

    by Lendrick ( 314723 ) on Monday April 28, 2003 @02:12PM (#5827405) Homepage Journal
    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.

  • FindBugs? (Score:4, Funny)

    by Copperhead ( 187748 ) <.talbrech. .at. .speakeasy.net.> on Monday April 28, 2003 @02:27PM (#5827649) Homepage
    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.

  • History, repeat thyself. (Score:3, Insightful)

    by pmz ( 462998 ) on Monday April 28, 2003 @02:27PM (#5827661) Homepage
    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.
    • 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?

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Monday April 28, 2003 @03:47PM (#5828647)
    Comment removed based on user account deletion

  • Jlint (Score:4, Interesting)

    by mmynsted ( 552933 ) on Monday April 28, 2003 @03:49PM (#5828680)
    OK.

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

    http://artho.com/jlint/

    --MM
    • Perhaps because jLint is written in C++, not Java.
    • Because it's research. Researchers need to be able to implement exactly the features they want to study, not what the developers and user base of an OSS project want. It's about the ideas, not the code. But I'm sure the authors would be pleased if JLint used their ideas.

  • The real value (Score:3, Interesting)

    by Dr. Bent ( 533421 ) <ben.int@com> on Monday April 28, 2003 @05:35PM (#5829666) Homepage
    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.
    • I would say that the real value of tools like this is that they teach you a lot about regexps and scripting. Because that's what you have to do to run them on a large project.

      You have to have scripts that deduct from coding style the author of each part of the project, and then invokes the code-checking tool with the right options to catch the types of errors that particular programmer is likely to make, but not giving 1999 false positives for each real error.

      Ok, I'm playing the devils advocate here, bu

      • Re:The real value (Score:3, Informative)

        by Dr. Bent ( 533421 )
        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 n

  • Something else worth a look (Score:3)

    by JediTrainer ( 314273 ) on Monday April 28, 2003 @10:15PM (#5831393)
    Another great tool that deserves a look (besides those already mentioned) is PMD [sourceforge.net]. 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.
    • Eclipse [eclipse.org] (also free and currently my IDE of choice) has more and more of these kinds of features built-in with each release.

      It's still mostly cleanup stuff, but it looks like they're moving towards having more of this stuff included by default. Currently you can set the error level (ignore, warning, error) when you do a build for unused imports/parameters/classes/methods/fields, circular dependancies, unreachable code, methods with constructor names, overridden methods that aren't package visible, hidden c
  • 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 (Score:3, Insightful)

    by Jason1729 ( 561790 ) on Monday April 28, 2003 @11:56PM (#5831824)
    How did you solve the halting problem? Or does it not check for potential infinite loops?

    Jason
    ProfQuotes [profquotes.com]

    • How did you solve the halting problem?

      Some cases of the halting problem are straightforward to accept or reject.

    • Re:Halting (Score:3, Insightful)

      by blancolioni ( 147353 )
      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.

  • PMD (Score:1)

    by insac ( 623145 )
    "...However, many of the
    detectors we have implemented, such as inconsistent
    synchronization and mutable static fields, are not
    present in PMD. Like our tool, PMD uses Visitors
    to implement its pattern detectors. One nice
    feature of PMD is that patterns may be implemented
    as XPath expressions, so that new checks can be
    added without the need to write a new Visitor
    class...."

    I'm wondering if they mean that their "detectors" (inconsistent synchronization and mutable static fields) can't be written in PMD XPath...

    Ot

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close