Tuesday 31 March 2015

Either/And/Or - How we find bugs

While I was chasing a bug this morning it occurred to me that I was caught in the usual trace/run/redo cycle, a cycle that's time-consuming though not nearly as using breakpoints.

How do programmers find and fix bugs? Setting breakpoints and tracing ultimately do the same thing, and seem to have roughly the same cost:

  • Set a breakpoint (or trace) to find out whether code is traversed or not.
  • Set a breakpoint (or trace) to find the value of something.
As to bugs, they tend to fall in 3 categories:
  1. Something happens, that shouldn't.
  2. Something doesn't happen, but should.
  3. Something happens in the wrong way.
#1, #3 are probably easier since we only need to map the symptom (bug report) to its immediate cause (code fragment) and get a stack trace for it. Finding this kind of bug becomes more time consuming when the target code is traversed very often, since we then have endless false positives.

#2 is often a lot trickier. It is solved by finding out how close we are to executing the desired code fragment so we have to use static analysis and potentially trace / break into all ancestors of a given target.

It seems to me that we could avoid spending so much time into the run/rerun/break/trace cycle.

No comments:

Post a Comment