Opening the discussion to include properties of nondeterministic bugs.

Often these bugs depend on timing, caused by unpredictable thread scheduling, CPU load, disk and networking timing, etc. Git commits can affect app timing and change the likelihood of the bug occurring, but in many cases these changes aren't related to the underlying bug. That's distinct from a regular git bisect to find a deterministic bug.

One cool bayesect application is to identify the commit that most frequently hits the bug, so it's easier to debug. But more broadly, I'm wondering about the underlying philosophy of bisection for nondeterministic bugs, and when I'd use it?

Bayesian bisection helps when the failure rate shifts enough to measure. Once a bug rides on scheduler jitter or some external side effect you don't control, the posterior gets mushy fast.

In practice bayesect gives you a ranked suspect list, and that's still better than poking at the repo blind, but calling the top commit "the cause" is where people fool themselvs. Half the time the winner only nudged timing and the bug still lives somewhere else.

[dead]