The ODB At Work
When I push zoom a second time, it displays the wrong data. Sometimes.
I had spent several hours looking for the bug with Eclipse. He was fairly sure that a certain ArrayList containing time-event pairs was being corrupted, but nothing more. He thought it would be interesting to try the ODB.
The EVolve visualization system comprises some 80K lines of Java and is designed to read-in and display performance data on Symbian applications for mobile phones. It had been written over several years by several programmers, none of whom were available. I had never used the tool, nor had I ever seen a single line of the source code. It was exactly what I was looking for!
The first indication of the problem was a dialog box that displayed a zero time. So I did an incremental search through the traces in the AWT thread for the string "Start time." Of the eight events, which contained that string, the second-to-last showed a zero time range.
I could see from the code that the string was constructed using the start and end instance variables from a Selection object. This particular object had the same value for both. Selecting that object and stepping back to its creation, I could see that RefDim.makeSelection() was calling new with those values. That method was called from Paladin.select(), which obtained those values by taking the difference between the start values of elements two and four of the aforementioned ArrayList. I noticed that the first five elements of the list were the same object.
Stepping backwards to find out who put those values in, I discovered this odd little loop, which ran in thread T1. (At this point, there is no clear connection between the creation of the list and its use.)
while ((x/Math.abs(interval) - xOffset) >= timeMap.add(time2event);
}
It was clear that multiple identical entries in the list were allowed, but that these particular ones were wrong. After staring blindly at the loop for a while, I stepped back to the caller:
countEvents(x + xOffset*interval);
The programmer was adding the offset to the X value, only to remove it in the loop. Weird. I had noticed that the second selection only failed if it were in a low range (presumably 0 - xOffset*interval, which was also the range where the ArrayList values were identical).
Removing the offset eliminated the bug. The entire session lasted about an hour, during which I looked at 20 objects in a dozen files. Most of my time was spent trying to understand the intent of the code.
—B.L.
