Quote: Bisection At 3AM

Submitted by Jeremy
on May 17, 2008 - 8:24am

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

What's a bisection?

Anonymous (not verified)
on
May 18, 2008 - 7:11pm

Some kind of source control business?

Kinda

Mr_Z
on
May 19, 2008 - 8:46am

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.

Anonymous (not verified)
on
May 19, 2008 - 12:17pm

Gotcha. Thanks Z.

Yay for kgdb

Anonymous (not verified)
on
May 17, 2008 - 9:39am

Kernel debuggers are your friend.

people overestimate kernel debuggers

sileNT (not verified)
on
May 17, 2008 - 11:28am

People (sometimes) overestimate kernel debuggers.

kgdb is not a panacea for all kernel problems.