Question

“Programming Pearls” in the column 2 (“AHA! Algorithm”) talks about how binary search aids in various processes like sorting, tree traversals. But it mentions that binary seach can be used in “program debugging”. Can somebody please explain how this is done?

Answer 1

Another possibility is that you have a bug, and you know it wasn’t there in your February release, but it was in your April release (or rather, your April release candidate — you would never actually ship a bug to your users, right?).

You can do a manual binary search through your revision-control history to narrow down when the bug was introduced. First check out the code halfway between the two releases, build it, and see if the bug is there. Keep partitioning until you find out when it was introduced. If you don’t know where to start looking for the bug, this can be very effective, especially if you do fairly small commits.

This works very well with Subversion because it has repository-wide revision numbers. If your February release was rev 533 and your April release was rev 701, then you update to rev 617, test it, and go from there. (Actually, I usually round to 600 so I don’t have to do so much math in my head.) Once I start to narrow it down, I start looking at the commit comments and making educated guesses (“I really don’t think this commit would have broken it”), so I usually don’t need to do all log₂(n) checkouts.

I’ve never used Git, but they take this one step further with the built-in “bisect” command. You give it a starting point (when was it known to work?) and ending point (when did you notice it was broken?), and it will automatically get the code for the halfway point in the binary search. Then after you’ve built and tested, you tell it whether this rev passed or failed; then it gets the code for the next halfway point. You can even tell it to run a command for each rev and use the command’s exit code to determine whether the rev is a pass or fail, at which point it can run on full automatic.