From: Daniel M Floyd
Subject: Favorite Debug Summary
Date:
Message-ID: <1650@wasatch.utah.edu>
The following is a summary of responses I've received on
the subject of favorite debugging techniques from the net. Most of the
things were fairly standard; however, there were a few exceptional
replies. I've made no attempt to organize this summary yet. I am
only listing features in a sort of random fashion. Some of the
items may be overlapping (i.e. 1 and 2). I've added some of my
own ideas and interpretations. If anyone sees omissions
- you don't see one you like - please let me know.
Many of the items were listed several times by various people.
My thanks to all the contributors. I'm sure many will benefit.
I'll let everyone know how things are going in a couple months.
(Obviously, everything won't be done in a couple months.)
1. Hypertext environment.
2. Windows (xwindows).
3. Need a 'debug language' to:
describe bugs
describe types of program alterations
describe the effects of program alterations
4. Expert system to use a and modify data base inherent in #3 so
expert advice would be available on line. Such an expert system
would include pattern recognition, associative memory.
5. Speed. Raw zoom-at-giga-hz speed.
6. Debug history function to record effects of modifications and
various inputs.
7. Documentation locator. "Where is that _____?"
8. Function locator. "Which file is ______ in?"
9. Trace on/off.
10. Output comparator. Find the differences/similarities between two
program runs.
11. Customizable display/keyboard etc.
12. Automatic *temporary* function creation and deletion. This
would create useful debugging functions that appear and
disappear for debug and non-debug modes respectively. All this
"automatic".
13. Extensible debugger to higher level of abstraction more
suited to application. For example, if FROBS is implemented in
lisp, and lisp has an examine structure debugger, the lisp debugger
should be extensible to examine FROBS structures/objects.
14. Interactively modify debug behavior during debugging.
This means modifying traces to ignore some functions, stopping
output, adding another item to show. Or do the same with step, or
whatever the debugger is doing.
15. Single step. From the abstract down to machine level on command.
16. Examine data structures on/off stack, variables, etc. (Inspector)
17. A way to answer at any time "what is happening now?" This would
be something you want when a program seems to be taking forever
and you suspect an infinite loop. But it would not halt execution
like ^C does but would simply say something like
"executing function foo for the 100th time..." and continue.
This is particularly needed when nothing seems to be happening.
18. Unique notes or tones assigned to "interesting" functions.
This suggestion shows a desire to have non-text based debugging
tools. The originator said there may not be any practical application;
however, I think IBM(r) among others has done something like that with
their POST and IBM-PC(r). They have something like 2 beeps for
one kind of error, three for another, one for all ok. Clearly useful.
For machines with better tone capabilities, the idea is quite reasonable.
19. Return with/without value to any function in an activation stack.
20. Higher abstraction levels. Don't say "...subtracted this and that
and added it to foo then divided by bar and divided by a number..."
Say instead "...computed standard deviation...".
21. Automated writing of data structure integrity check function. Such
functions would actively check constraints. For example, if
a list is to always be sorted, check that it is. Or if a list
is to have 5 members, automatically check for that condition.
22. Conditional and format triggered trace/step. Like if this
number changes or this function is true then start stepping.
23. Graphical representation of data structures. (More non-text.)
For example a tree would be shown as a tree.
24. A browser to interactively look at data structures.
This could work either on saved history states or as execution occurs.
Browser could work similar with #23.
25. Explore multiple possibilities at once. "Is one of these ... the problem?"
26. Breakpoint the nth call/return from a function. (Similar to 22.)
27. Interactively edit without leaving environment. Who cares how as long
as you don't ^Z fg %n edit... save ^Z fg %n2 load ...[(UNIX(R) AT&T) users
will recognize the sequence.]
28. Examine stack and local variable on the stack.
29. Continuing from a broken computation.
30. Compress redundant output in a debug trace. Could be something like
Instead of
enter:function1, enter:function1, enter:function1
enter:function1, enter:function1, enter:function1
enter:function1, enter:function1, enter:function1
Do
enter:function1 .. 9 <-this number could count up as we go
31. Mouse selectable list of options.
32. Concurrent display of source code with annotations
to show program execution state.
33. Able to evaluate expressions in current frame context of a backtrace.
34. Step that prompts on top level before entering a function
and prints after function evaluations.
35. Interested parties should read an article by Kent Dybvig,
Dan Friedman, and Chris Haynes found in the first issue of
LISP and Symbolic Computation. It is not limited to
debugging, but does have an interesting section about it.
Thanks again to the contributors (I hope I didn't accidentally omitt someone):
From: Dan Friedman <······@iuvax.cs.indiana.edu>
From: Lawrence G. Mayka <···@ihlpf.att.com>
From: Jeffrey Putnam <····@pawl.rpi.edu>
From: John Unruh <att!ihlpf!jdu>
From: Don Cohen <····@vaxa.isi.edu>
From: ·······@arisia.Xerox.COM (Ronald A. Fischer)
From: Paul Fuqua <·······························@cs>
From: ·······@aucs.UUCP (Dave Astels)
From: ······@syma.sussex.ac.uk (Aaron Sloman)
From: ····@zippy.eecs.umich.edu (Arie Covrigaru)
From: ·····@godot.radonc.unc.edu (Jesse Thorn)
Dan Floyd
8<D=