Re: Copy/paste issue.

[dkcombs@panix.com (David Combs)]

Talking about binary search for finding bugs.

In this thread you're talking about binary search on an input file.

Of course, you can also do that on the running of a program.  I
use a language ("MainSail") that makes that particularly simple.

When compiled debuggable, there places in the binary where
it lets you set breakpoints.

It also keeps a global variable "brkcnt", break-count, of
the number of possible places you could set a breakpoint
that you have run past thus far.

So, suppose that the program crashes at some surprise place,
and looking around in the debugger shows nothing obvious --
except, HEY!, how'd that file-pointer get nulled out (or
get changed to point not to a file, etc).

And there's nowhere nearby that that pointer gets played with.

What to do?  Well, you know what the current brkcnt is right now,
at the crash-point.  And you know that early on that file-pointer
was just fine.

So you start setting one breakpoint at each test run, and do
it by bisection.  For each run, when it breaks (at the current
bisection point), you check that pointer for correctness.  If
it's ok, you kill the program, reset the break point to halfway
between there and the crash point, and run it again.

If it's not ok, you kill the program, set the break point to
halfway in the other direction.

It's just amazing HOW FAST you can home in on THE instruction
that zeros the file pointer.  A million instructions (in YOUR
code, not non-debuggable libraries) range -- you find the
error point in just ten runs.

---

Well, I'm sure I'm not telling you guys anything new; you've probably
been doing this for decades.  But anyway, I thought it was pretty
cool, an easy way to home in on what would otherwise be an
almost impossible task to find.


David