"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.
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.
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.