On: Tracking down a kernel bug with git bisect

[Arnavion]

It's a pity that while the bisect did point in the general direction of where the bug was in 3.15, it didn't actually find the right bug (the one it found had already been fixed and a different one introduced that led to the same errant behavior).

With something as complex as the kernel, I also wonder about automatic bisect being led astray by unrelated changes. The bisect script might fail for a different reason and zone in on the wrong commit.

[chriscool → Arnavion]

The bisect pointed at the right patch series which is already very nice.

If the bisect script fails because of another problem, it is often possible to refine the script, or run bisect again on a fixed up branch.

[Arnavion → chriscool]

If I'm not mistaken, it didn't find the right patch series. The article says the function changed in 3.15 and the underlying reason for his issue was different and not part of that series.

[seabee → Arnavion]

When you update the kernel and your program stops working, there are two possibilities:

1) it's a kernel bug; there is a regression in the kernel's documented behaviour

2) it's a bug in your tool because it took advantage of undefined or undocumented behaviour

The bisect found exactly the right patch series, but bisect can only answer the question 'when did it stop working', not 'why'.

You can read about many instances of 2) on Raymond Chen's blog The Old New Thing.