| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Parts of this chapter are adapted from Don't Panic: A 6.001 User's Guide to the Chipmunk System, by Arthur A. Gleckler.
Even computer software that has been carefully planned and well written may not always work correctly. Mysterious creatures called bugs may creep in and wreak havoc, leaving the programmer to clean up the mess. Some have theorized that a program fails only because its author made a mistake, but experienced computer programmers know that bugs are always to blame. This is why the task of fixing broken computer software is called debugging.
It is impossible to prove the correctness of any non-trivial program; hence the Cynic's First Law of Debugging:
Programs don't become more reliable as they are debugged; the bugs just get harder to find.
Scheme is equipped with a variety of special software for finding and removing bugs. The debugging tools include facilities for tracing a program's use of specified procedures, for examining Scheme environments, and for setting breakpoints, places where the program will pause for inspection.
Many bugs are detected when programs try to do something that is
impossible, like adding a number to a symbol, or using a variable that
does not exist; this type of mistake is called an error.
Whenever an error occurs, Scheme prints an error message and starts a
new REPL. For example, using a nonexistent variable foo will
cause Scheme to respond
1 ]=> foo ;Unbound variable: foo ;To continue, call RESTART with an option number: ; (RESTART 3) => Specify a value to use instead of foo. ; (RESTART 2) => Define foo to a given value. ; (RESTART 1) => Return to read-eval-print level 1. 2 error> |
Sometimes, a bug will never cause an error, but will still cause the program to operate incorrectly. For instance,
(prime? 7) => #f |
In this situation, Scheme does not know that the program is misbehaving. The programmer must notice the problem and, if necessary, start the debugging tools manually.
There are several approaches to finding bugs in a Scheme program:
Only experience can teach how to debug programs, so be sure to experiment with all these approaches while doing your own debugging. Planning ahead is the best way to ward off bugs, but when bugs do appear, be prepared to attack them with all the tools available.
5.1 Subproblems and Reductions 5.2 The Command-Line Debugger 5.3 Debugging Aids 5.4 Advising Procedures
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Understanding the concepts of reduction and subproblem is essential to good use of the debugging tools. The Scheme interpreter evaluates an expression by reducing it to a simpler expression. In general, Scheme's evaluation rules designate that evaluation proceeds from one expression to the next by either starting to work on a subexpression of the given expression, or by reducing the entire expression to a new (simpler, or reduced) form. Thus, a history of the successive forms processed during the evaluation of an expression will show a sequence of subproblems, where each subproblem may consist of a sequence of reductions.
For example, both (+ 5 6) and (+ 7 9) are subproblems of
the following combination:
(* (+ 5 6) (+ 7 9)) |
If (prime? n) is true, then (cons 'prime n) is a reduction
for the following expression:
(if (prime? n)
(cons 'prime n)
(cons 'not-prime n))
|
This is because the entire subproblem of the if expression can
be reduced to the problem (cons 'prime n), once we know that
(prime? n) is true; the (cons 'not-prime n) can be
ignored, because it will never be needed. On the other hand, if
(prime? n) were false, then (cons 'not-prime n) would be
the reduction for the if expression.
The subproblem level is a number representing how far back in the
history of the current computation a particular evaluation is. Consider
factorial:
(define (factorial n)
(if (< n 2)
1
(* n (factorial (- n 1)))))
|
If we stop factorial in the middle of evaluating (- n 1),
the (- n 1) is at subproblem level 0. Following the history of
the computation "upwards," (factorial (- n 1)) is at subproblem
level 1, and (* n (factorial (- n 1))) is at subproblem level 2.
These expressions all have reduction number 0. Continuing
upwards, the if expression has reduction number 1.
Moving backwards in the history of a computation, subproblem levels and
reduction numbers increase, starting from zero at the expression
currently being evaluated. Reduction numbers increase until the next
subproblem, where they start over at zero. The best way to get a feel
for subproblem levels and reduction numbers is to experiment with the
debugging tools, especially debug.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are two debuggers available with MIT Scheme. One of them runs under Edwin, and is described in that section of this document (see section 7.6 The Edwin Debugger). The other is command-line oriented, does not require Edwin, and is described here.
The command-line debugger, called debug, is the tool you
should use when Scheme signals an error and you want to find out what
caused the error. When Scheme signals an error, it records all the
information necessary to continue running the Scheme program that caused
the error; the debugger provides you with the means to inspect this
information. For this reason, the debugger is sometimes called a
continuation browser.
Here is the transcript of a typical Scheme session, showing a user
evaluating the expression (fib 10), Scheme responding with an
unbound variable error for the variable fob, and the user
starting the debugger:
1 ]=> (fib 10)
;Unbound variable: fob
;To continue, call RESTART with an option number:
; (RESTART 3) => Specify a value to use instead of fob.
; (RESTART 2) => Define fob to a given value.
; (RESTART 1) => Return to read-eval-print level 1.
2 error> (debug)
There are 6 subproblems on the stack.
Subproblem level: 0 (this is the lowest subproblem level)
Expression (from stack):
fob
Environment created by the procedure: FIB
applied to: (10)
The execution history for this subproblem contains 1 reduction.
You are now in the debugger. Type q to quit, ? for commands.
3 debug>
|
This tells us that the error occurred while trying to evaluate the expression `fob' while running `(fib 10)'. It also tells us this is subproblem level 0, the first of 6 subproblems that are available for us to examine. The expression shown is marked `(from stack)', which tells us that this expression was reconstructed from the interpreter's internal data structures. Another source of information is the execution history, which keeps a record of expressions evaluated by the interpreter. The debugger informs us that the execution history has recorded some information for this subproblem, specifically a description of one reduction.
What follows is a description of the commands available in the debugger. To understand how the debugger works, you need to understand that the debugger has an implicit state that is examined and modified by commands. The state consists of three pieces of information: a subproblem, a reduction, and an environment frame. Each of these parts of the implicit state is said to be selected; thus one refers to the selected subproblem, and so forth. The debugger provides commands that examine the selected state, and allow you to select different states.
Here are the debugger commands. Each of these commands consists of a single letter, which is to be typed by itself at the debugger prompt. It is not necessary to type RET after these commands.
0 representing
the most recent time point, and ascending integers numbering older time
points. The u command moves up to older points in time, and the
d command moves down to newer points in time. The g
command allows you to select a subproblem by number, and the h
command will show you a brief summary of all of the subproblems.
pp) the
subproblem's expression.
lambda or let. These frames
collectively represent the block structure of a given environment.
Once an environment frame is selected by the debugger, it is possible to select the parent frame of that frame (in other words, the enclosing block) using the p command. You can subsequently return to the original child frame using the s command. The s command works because the p command keeps track of the frames that you step through as you move up the environment hierarchy; the s command just retraces the path of saved frames. Note that selecting a frame using p or s will print the bindings of the newly selected frame.
(abort->previous)
or use restart. The v command prompts for a single
expression and evaluates it in the selected environment. The w
command invokes the environment inspector (where); quitting the
environment inspector returns to the debugger. Finally, the o
command pretty-prints the procedure that was called to create the
selected environment frame.
The other two commands allow you to invoke internal continuations. This should not be done lightly; invoking an internal continuation can violate assumptions that the programmer made and cause unexpected results. Each of these commands works in the same way: it prompts you for an expression, which is evaluated in the selected environment to produce a value. The appropriate internal continuation is then invoked with that value as its sole argument. The two commands differ only in which internal continuation is to be invoked.
The j command invokes the continuation associated with the selected subproblem. What this means is as follows: when the description of a subproblem is printed, it consists of two parts, and "expression" and a "subproblem being executed". The latter is usually marked in the former by the specific character sequence `###'. The internal continuation of the subproblem is the code that is waiting for the "subproblem being executed" to return a value. So, in effect, you are telling the program what the "subproblem being executed" will evaluate to, and bypassing further execution of that code.
The z command is slightly different. It instead invokes the continuation that is waiting for the outer "expression" to finish. In other words, it is the same as invoking the j command in the next frame up. So you can think of this as an abbreviation for the u command followed by the j command.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section describes additional commands that are useful for debugging.
error) and a
read-eval-print loop is entered. The environment of the read-eval-print
loop is derived by examining the continuation of the call to
bkpt; if the call appears in a non-tail-recursive position, the
environment will be that of the call site. To exit from the breakpoint
and proceed with the interrupted process, call the procedure
continue. Sample usage:
1 ]=> (begin (write-line 'foo)
(bkpt 'test-2 'test-3)
(write-line 'bar)
'done)
foo
test-2 test-3
;To continue, call RESTART with an option number:
; (RESTART 2) => Return from BKPT.
; (RESTART 1) => Return to read-eval-print level 1.
2 bkpt> (+ 3 3)
;Value: 6
2 bkpt> (continue)
bar
;Value: done
|
pp procedure is described in section `Output Procedures' in MIT Scheme Reference Manual. However, since this is a very
useful debugging tool, we also mention it here. pp provides two
very useful functions:
pp will print the source code of a given procedure. Often, when
debugging, you will have a procedure object but will not know exactly
what procedure it is. Printing the procedure using pp will show
you the source code, which greatly aids identification.
pp will print the fields of a record structure. If you have a
compound object pointer, print it using pp to see the component
fields, like this:
(pp (->pathname "~")) -| #[pathname 14 "/usr/home/cph"] -| (host #[host 15]) -| (device unspecific) -| (directory (absolute "usr" "home")) -| (name "cph") -| (type ()) -| (version unspecific) |
When combined with use of the #@ syntax, pp provides the
functionality of a simple object inspector. For example, let's look at
the fields of the host object from the above example:
(pp #@15) -| #[host 15] -| (type-index 0) -| (name ()) |
pa prints the arguments of procedure. This can be used to
remind yourself, for example, of the correct order of the arguments to a
procedure.
for-all?
=> #[compiled-procedure 40 ("boole" #x6) #xC #x20ECB0]
(pa for-all?)
-| (items predicate)
(pp for-all?)
-|(named-lambda (for-all? items predicate)
-| (let loop ((items items))
-| (or (null? items)
-| (and (predicate (car items))
-| (loop (cdr items))))))
|
where enters the environment examination system.
This allows environments and variable bindings to be examined and
modified. where accepts one-letter commands. The commands can
be found by typing ? to the `where>' prompt. The optional
argument, obj, is an object with an associated environment: an
environment, a procedure, or a promise. If obj is omitted, the
environment examined is the read-eval-print environment from which
where was called (or an error or breakpoint environment if called
from the debugger). If a procedure is supplied, where lets the
user examine the closing environment of the procedure. This is useful
for debugging procedure arguments and values.
#f if environment is specified, and #t if
environment is not specified.
(apropos "search") -| #[package 47 (user)] -| #[package 48 ()] -| list-search-negative -| list-search-positive -| nt-fs-flag/case-sensitive-search -| re-string-search-backward -| re-string-search-forward -| re-substring-search-backward -| re-substring-search-forward -| search-ordered-subvector -| search-ordered-vector -| search-protection-list -| string-search-all -| string-search-backward -| string-search-forward -| substring-search-all -| substring-search-backward -| substring-search-forward -| vector-binary-search |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Giving advice to procedures is a powerful debugging technique.
trace and break are useful examples of advice-giving
procedures.
Note that the advice system only works for interpreted procedures.
[Entering #[compound-procedure 1 foo]
Args: val1
val2
...]
|
where val1, val2 etc. are the evaluated arguments supplied to the procedure.
(trace-entry fib) (fib 3) -| [Entering #[compound-procedure 19 fib] -| Args: 3] -| [Entering #[compound-procedure 19 fib] -| Args: 1] -| [Entering #[compound-procedure 19 fib] -| Args: 2] => 3 |
(trace-exit fib) (fib 3) -| [1 -| <== #[compound-procedure 19 fib] -| Args: 1] -| [2 -| <== #[compound-procedure 19 fib] -| Args: 2] -| [3 -| <== #[compound-procedure 19 fib] -| Args: 3] => 3 |
trace-entry and trace-exit on
procedure. trace is the same as trace-both.
(trace-both fib) (fib 3) -| [Entering #[compound-procedure 19 fib] -| Args: 3] -| [Entering #[compound-procedure 19 fib] -| Args: 1] -| [1 -| <== #[compound-procedure 19 fib] -| Args: 1] -| [Entering #[compound-procedure 19 fib] -| Args: 2] -| [2 -| <== #[compound-procedure 19 fib] -| Args: 2] -| [3 -| <== #[compound-procedure 19 fib] -| Args: 3] => 3 |
trace-entry with the additional effect that a breakpoint is
entered when procedure is invoked. Both procedure
and its arguments can be accessed by calling the procedures
*proc* and *args*, respectively. Use restart or
continue to continue from a breakpoint.
trace-exit, except that a breakpoint is entered just prior
to leaving procedure. Procedure, its
arguments, and the result can be accessed by calling the procedures
*proc*, *args*, and *result*, respectively. Use
restart or continue to continue from a breakpoint.
break-entry and break-exit combined.
The following three procedures are valid only within the dynamic extent of a breakpoint. In other words, don't call them unless you are stopped inside a breakpoint.
The following procedures install advice procedures that are called when the advised procedure is entered or exited. An entry-advice procedure must accept three arguments: the advised procedure, a list of the advised procedure's arguments, and the advised procedure's application environment (that is, the environment in which the procedure's formal parameters are bound). An exit-advice procedure must accept four arguments: the advised procedure, a list of the advised procedure's arguments, the result yielded by the advised procedure, and the advised procedure's application environment.
Note that the trace and breakpoint procedures described above are all implemented by means of the more general advice procedures, so removing advice from an advised procedure will also remove traces and breakpoints.
unadvise-entry and unadvise-exit. If
procedure is not given, the default is all advised procedures.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |