findbugs is a binary static analysis tool for Java bytecode binaries. I used it on my project for the last few days, here are some initial impressions.

---

Having written a binary static analysis product that analyzed Java binaries (among other platforms), I'm always interested to get a feel for what similar products do and don't do. findbugs appears to be very much like FxCop and Gendarme for .NET binaries. None do inter-function value tracking; they analyze each function as a unit, but not how functions interact with eachother. (Our binary static analysis product did do inter-function and inter-module analysis. Hopefully open source projects like bugreport pick up the gauntlet soon.) PC-Lint , which does analysis on C/C++ source code, does do inter-function value tracking -- and a very good job of it.

As I said in the BlackHat training that Luis Miras and I gave, some useful bugs can be found without inter-function analysis. FxCop can detect when Dispose() is being called within Dispose(), when Finalizers are accessing class fields, etc. Those are real issues, but they aren't exploitable bugs by any stretch of the imagination. The ability to detect exploitable bugs requires the ability to track user-supplied (tainted) data across function boundaries and find when it is used insecurely. findbugs is able to find similar bugs to FxCop, which does provide some value. They're both free, which is appropriate for the value they provide ;>

findbugs was able to detect a couple of interesting bugs. The most interesting of which, and one we focused on in BugScan, was adding non-Serializable classes to the Session. This is a really serious issue that only manifests itself under load. You'll think everything is great until you get a couple hundred/thousand users, and then your app will start barfing. It's very unfortunate when this happens, because it's usually just as a site it getting popular and a good user base and then the users abandon it because of the flakiness that starts happening. This was actually quite a bit of work to fix, because not only did classes have to marked Serializable, but all the types they used in their fields also has to be Serializable. I got most of them, but there are a few I couldn't fix due to the way JBoss dictates design and I wasn't able to refactor into a design that would allow me to fix it entirely. (I really don't care for JBoss or JSF because of crap like this.)

Next up was a couple of bugs that came out of a lack of pairing. I say this, because if another pair of eyes had been on the code then these obvious bugs would have been fixed before they were even compiled. Also, a pair would have kept the programmer honest, making them write a unit test that would have easily discovered the bug. The first bug looked like this:

if (null == foo) {
 // [code that handled things literally commented out]
}
if (foo.Equals("baz")) {
 // ...
}

Here, the null check was pointless because the reaction to the null value being present was commented out. As a result, if a null got into the method, it would crash on the next if() where foo is deferenced. Oops. The similar one was almost the same (a copy & paste culprit, if I had to guess), but was handling things in the null check. The rest of the method shouldn't be executed in that context, and the programmer forgot to either return after handling the null, or put an else on the second if() statement. Those are pretty cool little bugs to find, and findbugs was pretty quick about it on the 30KLOC in the EJB portion of the codebase. It also found empty catch{} blocks and potential null derefs.

Unfortunately, it didn't really understand the JBoss/SEAM idea of inject and outject via @In and @Out annotations. As such, there were a fuckton of warnings about fields never being read or written which were false positives. Also, the GUI was very annoying to use and I could never get the filtering or the source code lookup to work correctly. It was a little better working from current CVS rather than the stable release, but not by much.

All in all, I'd say to give it a look and try the following commandline options: -effort:max -medium -experimental . It only took me an hour or two to go through all of them, and the bugs I was able to find and eliminate were worth that minimum effort.

Discussion: showing all 0 messages

(No messages)

>

Post a new message:

---