Bisecting a bug instead of staring at it
Halve the search space, twice, and a mystery becomes a line number. It works on commits, on inputs and on the code itself.
Bisection needs one thing: a reliable, fast test for whether the bug is present. Given that, git bisect finds the commit that introduced it in log2(n) steps, about ten checks across a thousand commits, and with bisect run it does them itself while you make tea. The commit that broke it usually explains why, and the diff is usually small.
The same halving works without version control. Delete half the input and see if it still fails. Comment out half the module. Stub half the dependencies. Each step either halves the problem or tells you that half was innocent, which is also progress. Debugging by reading gets slower as the code gets bigger; debugging by bisection barely notices.
The prerequisite is the reproduction, and it is worth spending real time on. An intermittent bug is a bug whose trigger you have not identified yet, and turning it into a deterministic one, fixed seed, fixed clock, fixed ordering, is usually most of the fix. It also means you can tell whether you actually fixed it.
You should now be able to
- Use git bisect against a reliable reproduction
- Reduce a failing input to the smallest case that still fails
Loading…