🚀 go-pugleaf

> (In the header: From: csm@violet.berkeley.edu)
> (In body of article: Brad Sherman (bks@ALFA.Berkeley.Edu))

> There are certain classes of bugs for which fancy debuggers
> are terrific.  [... such as segmentation violation ...]
> However, more other sorts of  bugs, like omitting an '=' to yield
> 	if ( x = y ) /* Assignment */
> [... where a test was intended ...] are not found quite so quickly.

There is a small kernel of truth here, but the situation is not as
"binary" as suggested above.  That is, the model of considering that
there are two categories into which bugs fall, "debuggers useful in
diagnosing", and "debuggers not useful in diagnosing", (and the
majority of bugs in the latter categories) is a poor model.

A better model is that bugs manifest themselves in ways increasingly
separated from their ultimate cause, and the more powerful a debugger,
the more separation from cause to manifestation can be "backtracked"
without resorting to the inclusion of special-purpose traceing or
self-checking code.

For example, take a debugger that can walk back stacks, and position
to stack frames other than the most recent.  It can trace back the
origin of improper arguments, while a debugger lacking this feature
can do it clumsily at best.  Trust me that this is true: I've used
both types of debuggers.

And, to address directly the "if ( x = y )" type of bug, there are
many fancy features that would help ferret this out.  Such as
selective variable value tracing (if the bug manifestation pointed to
x as a trashed variable), or by-source-line stepping (if the bug
manifestation pointed to the failing routine's flow of control), and
so on.  The point here is that the example of accidental assignment is
NOT an example that fits cleanly into the "fancy debuggers are
useless" category.

The more general point is, the "fancier" the debugger, the larger the
class of bugs that become trivial to diagnose.  "Trivial", in this
case, implies a saving in the developer-diagnostician's time.

> I have no data, but I would suspect that given a corpus of
> differing bugs, debugging time is directly proportional
> to the skill of the programmer with only slight gains to be had
> from sophistication of tools.

My personal experience is directly contrary to this assertion, so I
suspect it is incorrect.  In particular, I can find problems many
times as fast using a gdb-class or better debugger than I can using
an sdb-class or worse debugger.  I don't keep formal statistics on
this point, but a measure of bugs-diagnosed-per-day is definitely
improved by better debugging tools.

> The most important element of the debugging tool is probably the
> amount of time it takes from hypothesis to rerun.

That may well be.  And with a sufficiently powerful debugger, this can
be reduced to (about) zero.  For example, debuggers which allow the
insertion of interpreted code into compiled code allow checking of
hypothesis with no compile/link process to slow things down.

> The most important skill is learning how to develop the hypothesis.
> (Unless tenacity is considered a skill.)

Yes, that is the most important *skill*.  But the most impotant *tool*
is one that allows the verification of the hypothesis at least cost.
This is what debuggers are all about, and the "fancier" they are, the
more classes of hypothesis they can verify at low cost.

To directly answer the question in the "subject" line, I don't really
have any one "favorite" debugger technique.  I think that the various
methods of forming the hypothesis of the nature of the bug is the hard
part, and I only vaguely understand how I do this myself.  But even a
genius at this is handicapped if this genius lacks adequate tools to
explore the buggy process to test the hypotheses as they are thought
of.

--
And you may find yourself in a beautiful house, with a beautiful wife
And you may ask yourself -- Well ... how did I get here?
                    --- "Once in a Lifetime" by Talking Heads
--
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw