Improving Spotbugs XML Output

[bugh1]

1.txt
2.txt
3.txt

Right now, there seems to be no way to properly identify the code flow for a bug instance based on the XML output.

Attached at the top are three examples of bugs reported by spotbugs. Each attached text file contains a complete <BugInstance> tag as reported by the tool as well as a code snippet associated with the bug reported.

Starting with the first example, using each line numbers as a node and then examining the source code to determine the appropriate edges, we get the following graph:

line 135
|
V
line 287
|
V
line 47 <- line 108
|
V
line 64
|
V
line 70 <- line 80
|
V
line 71 (primary=true)

As you can see, there are multiple flows that leads to the primary location of the bug. However, the XML output lists each line as separate <SourceLine> tags, and does not display how each line relates to each other leading to the primary location. All we get is a list of <SourceLine> tags all contained in a <BugInstance> tag. The xml output alone does not provide information to get the edges in the graph.

The second text file attached is a listing of another BugInstance. Again using the line numbers reported as a node, we get the following graph:

line 67 (primary=true)
|
V
line 74

In contrast with the first example, this example shows that the primary SourceLine is the initial source of the error, whereas in the first example the primary SourceLine is the final source of the error.

The third text file attached is also a listing of another BugInstance. Specifically, this example suggests that the listing of the <Method> tags can also be improved. The method names, listed in order of the output in the XML file are:

• testScientificDouble (primary=true)
• <init>
• valueOf
• equals
• assertEquals

They seem to be just a lists of method names encountered in a path. Although in this case 4 of the tags contained a role attribute, the code flow is not immediately clear. Perhaps more information could be added in order to provide a more accurate representation of the flow to a bug and to show how each method relates to the other.

It is also worth noting that the html report obtained by converting the xml output does not seem to provide a better understanding of the code flow, as they are just a list of messages that appeared in order of a BugInstance (aside from the descriptions of the bug types).

The source code for the examples described can be obtained at: https://github.com/unclebob/fitnesse/releases/tag/20130530

Also, a new standard output format for static analysis tools called SARIF (Static Analysis Results Interchange Format, version 2.0) is being developed and it has fields for code flows, so perhaps support for this format could be added in the future?
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif
https://github.com/oasis-tcs/sarif-spec