Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!mcnc!rti!xyzzy!agarn!throopw From: throopw@agarn.dg.com (Wayne A. Throop) Newsgroups: comp.cog-eng Subject: Re: Debug techniques. What's your favorite? Message-ID: <5338@xyzzy.UUCP> Date: 24 Apr 89 19:43:55 GMT References: <1499@wasatch.UUCP> <877@syma.sussex.ac.uk> <22878@agate.BERKELEY.EDU> Sender: usenet@xyzzy.UUCP Lines: 81 > (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 !mcnc!rti!xyzzy!throopw