FindBugs

Locating and fixing software defects (bugs) is one of the most expensive tasks involved in software development. Because of this, software projects benefit greatly from tools that can automate the process of locating them. This is often accomplished using a technique called "static analysis", which examines the software and extracts useful knowledge from it. One such popular static analysis tool for Java programs is FindBugs. FindBugs examines the byte code of compiled Java classes for well known "bug patterns" that indicate possible defects and reports them with detailed information about the pattern it detected and why it may be a problem. FundBugs has an extensive database of these bug patterns and is quite good at locating hidden problems within even mature codebases.

For this laboratory exercise we will walk through the process of getting FindBugs up and running. We will then have it analyze a version of the previously introduced JUnit test framework. You will then be asked to provide some detailed analysis of the generated report and to offer up a proposed fix for the identified bug. Let's get to it!

Getting FindBugs

FindBugs is available as a stand alone program (info), but as with many popular Java development tools it has also been developed into an Eclipse plugin. To install the plugin use Eclipse's "Help -> Install New Software..." menu item. The "Install" dialog will appear. Select the "Add..." button and create a new software repository for:

http://findbugs.cs.umd.edu/eclipse-candidate/

The "Add Repository" dialog should match the screenshot below:

Click "OK" and you'll be returned to the "Install" dialog which will be loaded with the FindBug plugin as an option (after a short delay). Click the top level "FindBugs" entry as shown below:

Click "Next", and the "Install Details" will appear. Click "Next" again and you will be prompted to review the licensing agreement. If you agree to the terms shown, select the radio button indicating that you accept the terms and click "Finish". Installation will begin (you may be prompted about the software being unsigned, this is normal and you can indicate that installation should continue). Upon completion you should "Restart Now" as suggested. Once Eclipse has restarted you now have FindBugs capabilities in your Eclipse installation. Now we will use FindBugs to analyze a project.

Using FindBugs

Refer to the version control lab if you need a refresher on how to check out a project from Subversion into Eclipse.

First we'll need a project to analyze. For this we'll use the source code from the JUnit project we have used previously in this class. We have pulled the actual JUnit code into the course repository (slightly modified to remove external dependencies). Check out this version from the following URL:

http://subversion.assembla.com/svn/ee461l-findbugs/

Right click on the newly created JUnit project and select the "FindBugs -> Find Bugs" menu item. This will kick off the static analysis process. When FindBugs finishes analyzing the project it will give you a summary of the issues it found and ask if you wish to switch to the FindBugs perspective as seen below:

Select "Yes" and the Findbugs perspective will be displayed. By default, the issues it identified will not be shown with their categories. We will need to know what categories the issues fall into as part of the exercise for this lab assignment so let's modify the "Bug Explorer" view to show the issues in their categories. To do this, click the "Change Bug Explorer Grouping" button from the view's toolbar as called out below:

This will bring up the "Bug Group Configuration" dialog. In this, deselect everything except for the "Category" and "Pattern" items. Also, move the "Category" item to the top of the list. Your final configuration should appear as follows:

Select "OK" and this will reorganize the list of issues into convenient categories. Let's take a look at one of the identified issues: expand the tree items for the "Bad practice" category and further expand the "Method may fail to close stream" entry. Double click on the issue: the source pane wil be updated with the referenced location and the properties will show a detailed description of the problem findbugs believes it has identified. Your screen should appear as follows:

The problem here is that the method opens a "FileInputStream", but does not ensure that it is closed. Each stream that is opened consumes a file descriptor and the operating system often limits the number of file descriptors a process can have open at any given time. Forgetting to close descriptors causes your program to "leak" file descriptors. If the program runs long enough (and "readPreferences" is called often enough), eventually the operating system will not allow the program to open any additional files. This is a perfect example of a programming issue that is very easy to miss when writing (and also reviewing) your code. This is where FindBugs shines and it is pretty clever in being able to detect them!

So how could we fix this? FindBugs suggests including a "finally" block to ensure that the stream is closed. This is exactly what is needed and leads to the following solution in code:

 	private static void readPreferences() {
 		InputStream is= null;
 		try {
 			is= new FileInputStream(getPreferencesFile());
 			setPreferences(new Properties(getPreferences()));
			getPreferences().load(is);
		} catch (IOException e) { } 
		finally {
			try {
				if (is != null)
					is.close();
			} catch (IOException e1) { } // Fail silently
		}
 	}

This will remove the file descriptor leak and pre-emptively avoids future headache when trying to track down the bug.

Exercise
Review the other issues identified by FindBugs for the JUnit source code. Select three of them and provide the following:

Reiterate the identified issue in your own words to demonstrate your understanding of the reported problem.
Describe what needs to be done in order to fix the issue.
Provide source code implementing the fix.

Alternatively, you can identify an issue which you feel does not need to be addressed with any changes. If you choose this route, be sure to provide a strong case as to why this issue represents a false positive. Note: you must select at least one issue that you feel should be fixed (i.e.: you may not select three items that you feel do not need to be corrected).

Reference materials:

FindBugs Manual

Developed with guidance from Miryung Kim

Copyright (c) 2011 Professor Miryung Kim and a course development TA Evan Grim

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the GNU web site here.