"Have you ever been an hour and a half into a bisection at 3AM then hit a massive oops deep in the TCP code which was spread across a large number of commits? I have and it wasn't fun. If I remember correctly I gave up and went to bed."
The basic idea is to try a binary search on a stream of patches to narrow down which patch triggers a bug. (It's important to note that the patch itself may not contain the bug, but the patch may expose a bug created elsewhere.)
So, given working kernel A, and not-working kernel B and a series of patches between A and B, you can bisect the stream, apply half of the patches, and get a kernel halfway between A and B. Depending on whether that kernel exhibits the same bug, you can then subdivide the halves to either side, etc. until you get down to the error-causing patch.
For certain classes of bug, this works very well. For many others, not so much. Timing bugs / race conditions can fall into that latter category.
Yay for kgdb
Kernel debuggers are your friend.
people overestimate kernel debuggers
People (sometimes) overestimate kernel debuggers.
kgdb is not a panacea for all kernel problems.
What's a bisection?
Some kind of source control business?
Kinda
The basic idea is to try a binary search on a stream of patches to narrow down which patch triggers a bug. (It's important to note that the patch itself may not contain the bug, but the patch may expose a bug created elsewhere.)
So, given working kernel A, and not-working kernel B and a series of patches between A and B, you can bisect the stream, apply half of the patches, and get a kernel halfway between A and B. Depending on whether that kernel exhibits the same bug, you can then subdivide the halves to either side, etc. until you get down to the error-causing patch.
For certain classes of bug, this works very well. For many others, not so much. Timing bugs / race conditions can fall into that latter category.
--
Program Intellivision and play Space Patrol!
Gotcha. Thanks Z.
Gotcha. Thanks Z.