The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and...

18
The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector Using them is partially implementation dependent, so we will examine these as seen in LispWorks • we will also briefly look at two other useful tools, step and trace The debugger is entered whenever an error arises when executing or compiling code, or if a program calls one of the functions error, cerror or break • You can also enter the debugger any time you want in LispWorks by typing <cntl>+<break> The debugger provides for you two important pieces of information: • The error message • A stack backtrace so that you can see what functions were active when the error arose The debugger provides for you a list of options that you can select between to proceed • This list is partially based on the error itself as we will see

Transcript of The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and...

Page 1: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

The Debugger and Inspector• Two very useful tools available in Common Lisp are the

debugger and inspector– Using them is partially implementation dependent, so we will

examine these as seen in LispWorks• we will also briefly look at two other useful tools, step and trace

– The debugger is entered whenever an error arises when executing or compiling code, or if a program calls one of the functions error, cerror or break

• You can also enter the debugger any time you want in LispWorks by typing <cntl>+<break>

– The debugger provides for you two important pieces of information:

• The error message• A stack backtrace so that you can see what functions were active when

the error arose– The debugger provides for you a list of options that you can

select between to proceed• This list is partially based on the error itself as we will see

Page 2: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Cause 1: Arithmetic Error• Consider doing (/ 3 0), you will be dropped into the debugger with

the following options:

• The first choice allows you to abort the function but have it return a value– this is more useful if the function was being called from inside another

function so that we can proceed from this point by supplying a return value• The second choice allows you to replace the 0 in the denominator

– this allows you to proceed as if the error did not arise by replacing the erroneous value with something else

• You can return to the top level, either by aborting (in which case everything is reset) or not aborting (any values changed prior to the error remain changed)

Error: Division-by-zero caused by / of (3 0). 1 (continue) Return a value to use. 2 Supply new arguments to use. 3 (abort) Return to level 0. 4 Return to top loop level 0.

Page 3: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Cause 2: Unknown Identifier

• The reason for the first response is that it is possible that C will gain a value from elsewhere– Say if we had multiple processes running

• Using :C allows us to change an unbound variable for the value :C, but unfortunately it will lead to another error because we cannot add a non-number

• Supplying a value for C is the most useful – notice we can supply C a one-time value (3) or a permanent value (4)

CL-USER 123 > (+ c 5)

Error: The variable C is unbound. 1 (continue) Try evaluating C again. 2 Return the value of :C instead. 3 Specify a value to use this time instead of evaluating C. 4 Specify a value to set C to. 5 (abort) Return to level 0. 6 Return to top loop level 0.

Page 4: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Examining the Stack• One of the commands that you can always try is to evaluate

the run-time stack– In LispWorks, do :b at the debugger prompt

• :bb gives you a reduced (brief) backtrack and :bq gives you an even shorter backtrace

• This will list all of the function calls leading up to the error– Notice aside from the program’s functions, we also have various OS

function calls which mostly we won’t need to know about

Interpreted call to COMPUTEFITNESSESInterpreted call to SELECTVECTORSInterpreted call to EVOLVECall to SPECIAL::%EVAL-NOHOOKCall to IV:PROCESS-TOP-LEVELCall to CAPI::CAPI-TOP-LEVEL-FUNCTIONCall to CAPI::INTERACTIVE-PANE-TOP-LOOPCall to (SUBFUNCTION MP::PROCESS-SG-FUNCTION

MP::INITIALIZE-PROCESS-STACK)

From the GA code, I placeda break in computefitness

You can see that evolvecalled selectvectors whichcalled computefitnesses

The rest of the calls are fromthe CL environment & OS

Page 5: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Example

• To the right is the backtrace provided– ignoring the calls prior to the

intepreted call, we can see that weirdfact was invoked 4 times (n = 5, n = 3, n = 1, n = -1)

– we can therefore see when we ran into problems

– we can also inspect the stack values (as we will see shortly)

• If I resume execution, we enter an infinite loop – however I could first alter n (say

to be even) before resuming to avoid the infinite loop

(defun weirdfact (n) (if (< n 0) (break)

(if (= n 0) 1 (* n 2 (weirdfact (- n 2))))))

We will only reach the break if weirdfact iscalled with an odd numbered parameter

Calling (weirdfact 5) leads to a break with thefollowing backtrace:

Interpreted call to WEIRDFACTInterpreted call to WEIRDFACTInterpreted call to WEIRDFACTInterpreted call to WEIRDFACTCall to SPECIAL::%EVAL-NOHOOKCall to IV:PROCESS-TOP-LEVELCall to CAPI::CAPI-TOP-LEVEL-FUNCTIONCall to CAPI::INTERACTIVE-PANE-TOP-LOOPCall to (SUBFUNCTION MP::

PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK)

Page 6: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Some Debugger Commands• :v Print the current frame• :bq Print quick backtrace of

interesting frames limited to m calls if we supply m (:bq 5)

• :b Print backtrace from the current frame

• :error Print the error and how to continue

• :n Go down the stack by 1 (:n m goes down by m)

• :p Go up the stack (:p m goes upby m)

• :top Abort to top level• :a Abort one level• :c Continue from error• :ret Return from frame• :res Restart frame• :sres Restart frame, stepping the

function• :< Go to the top of the stack• :> Go to the bottom of the stack• :cc Get the current condition object

• :l Print/return value of given variable in current frame.

• :show Print all objects found in stack frame

• :grab Grab all objects from a stack frame• :bb Print a full backtrace suitable for a

bug report• :lambda Show lambda expression for frame• :get <variable> <command identifier> Get

a command from the history list and put it in a variable.

• :help Produce help list.• :his &optional <n1> <n2> List command

history.• :redo &optional <command identifier> Redo

a previous command, identified by its number or a substring.

• :use <new form> <old form> &optional <command identifier> Redo command after replacing old form with new form.

Page 7: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Example• Consider the following function

– (defun foo (lis1 lis2) (let (temp) (dolist (a (append lis1 lis2)) (if (atom a) (setf temp (append temp (list a))))) temp))

• Called by (foo ’(a b c) ’d)– since ’d is not a list, append in dolist gives us an error and drops us in the

debugger with the message• Error: D is not of type LIST. • 1 (abort) Return to level 0. • 2 Return to top loop level 0.

– entering :b gives us the stack trace:• Interpreted call to FOO• Call to SPECIAL::%EVAL-NOHOOK• Call to IV:PROCESS-TOP-LEVEL• Call to CAPI::CAPI-TOP-LEVEL-FUNCTION• Call to CAPI::INTERACTIVE-PANE-TOP-LOOP• Call to (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-

PROCESS-STACK)

– not very helpful!

Page 8: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Example Continued• If we do :v we get back the active values on the stack

– Interpreted call to FOO:– LIS1 : (A B C)– LIS2 : D– TEMP : (A B C)– A : C

• And we can see how these are used if we either do (pprint #’foo) or :lambda– #.#'(LAMBDA (LIS1 LIS2)– (DECLARE (LAMBDA-NAME FOO))– (BLOCK FOO (LET (TEMP) (DOLIST # #) TEMP)))

• Does this help? – notice for (dolist …) we don’t get to see everything, but we can further

inspect the # #• What do we do here? The error arose because lis2 is not a list

– do (setf lis2 ’(D)) and then :res (restart the current frame)– this restarts foo, which can now continue until it completes, in this case

returning (A B C D)

Page 9: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Debugger Activities• First, identify the cause of the error• Next, move down the stack looking over the function calls• At each stack frame, you can examine the local variables

using :v, :show, or :l <name> in some combination– you can change the value of a local variable or parameter using setf– if, in moving around, you forget the error or continuations, type :error– :< and :> take you to the top and bottom of stack respectively if you need to

quickly get to one end • for instance, if you’ve moved down several frames, get back to the top by :<

• If you have identified the cause of the error and fixed it by altering a value, you can restart from the point of error by doing :res (but first go to the top of the stack)

• If you are still unsure, move to several stack frames prior to the error and do :sres (invokes the stepping function, which we will examine later)

• If you want to give up, you can abort :top or abort 1 level :a or use the continuation that takes you to the top level

Page 10: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Inspecting the Stack• CL has a built in inspector which allows you to

inspect any stack object– describe is a text-based function to inspect an object

• this lists the object, and its component parts if it is a sequence, structure or object

– inspect does the same thing but is interactive• this does the same as describe but drops you into the

interactive inspector– the interactive inspector is much like the debugger, you can inspect

what is going on in the object just as you inspect what is going on in the stack with the debugger

• once in the inspector, you can examine any individual component, or change components

– for instance, if the object is a list, you can examine each list element, or change any list element

Page 11: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Inspector Commands• :d Display current object.• :dm Display more of current object (if you can’t see the entire object at one

time)• :sh Show inspector stack.• :u Undo last inspection.• :ud Undo last inspection and redisplay.• :q Quit from current inspector.• :s :s n v sets slot n to value v.• :i Recursively invoke a new inspector.• :m Display possible modes or change mode.• :cv Current values of control variables within inspector.• :h Help on inspector commands.• :get <variable> <command identifier>

Get a command from the history list and put it in a variable.• :help Produce this list.• :his &optional <n1> <n2>

List the command history, optionally the last n1 or range n1 to n2.• :redo &optional <command identifier>

Redo a previous command, identified by its number or a substring.• :use <new form> <old form> &optional <command identifier>

Redo command after replacing old form with new form.

Page 12: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Example• (setf a '(1 2 a "abc" #(z y x) #(9 8 77 66 55)))

(describe a)

(1 2 A "abc" #(Z Y X) #(9 8 77 66 55)) is a LIST0 11 22 A3 "abc"4 #(Z Y X)5 #(9 8 77 66 55)

(inspect a)

(1 2 A "abc" #(Z Y X) ...) is a LIST0 11 22 A3 "abc"4 #(Z Y X)5 #(9 8 77 66 55)

Inspect 1 > 3"abc" is a SIMPLE-BASE-STRING0 #\a1 #\b2 #\c

Inspect 2 > :uInspect 1 > 4

Selecting 3 recursively inspects itand we are moved into a lower levelof the inspector

:u returns us to the previous level

Selecting 4 will inspect #(Z Y X)

Page 13: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Changing Values• The :s command allows us to change the value of a component of

the inspected object– :s 2 ’b changes a to become (1 2 B "abc" #(Z Y X) #(9 8 77 66 55)))– :s 3 ’c changes a to become (1 2 B C #(Z Y X) #(9 8 77 66 55)))

• We can change any value we want, even one of the vectors– from inspect 1 > 4 – to inspect item 4– now we are inspecting the vector #(Z Y X)– :s 2 ’q a is now (1 2 B C #(Z Y Q) #(9 8 77 66 55))

• The inspector can be invoked from inside of the debugger so this makes it easy to check out the value of variables and make changes to them before resuming your function (if desired)– inspecting sequences, structures and objects is far more useful than

inspecting simpler types#S(PERSON :NAME FRED :SEX M :AGE 31 :OCCUPATION NONE) is a PERSONNAME FREDSEX MAGE 31OCCUPATION NONE

Inspecting a structure of type Personwe can reset a value using :s age 32 or:s occupation ’plumber

Page 14: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Stepping Through Code• The Stepper is a tool that lets you step through code

– In LispWorks, there is a graphical stepper tool (click on the boot-shaped icon, or select Stepper from the Tools menu)

• I haven’t been very successful in using this, so instead:

– The stepper is also available at the command prompt, just like the debugger and inspector

• type (step (functioncall params))• this brings you into the stepper where you can step through the

execution of the function

– :s steps down one level of the current function, or steps through the next function

• for instance, (let ((a (/ x 2))) :s first steps into let, then steps into the assignment of a, then steps into the divide, then returns to the assignment of a

– :st steps through the current function without stepping through its specific subparts

Page 15: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Stepper Example(defun bar (a b) (cond ((< a b) (- a b)) (t (+ a b))))(step (bar 3 5))

(BAR 3 5) -> :s 3 -> :s 3 5 -> :s 5 (DECLARE (SPECIAL:SOURCE (LAMBDA (A B)

(DECLARE (LAMBDA-NAME BAR)) (BLOCK BAR (COND ((< A B) (- A B)) (T (+ A B)))))) (LAMBDA-NAME BAR)) -> :s

NIL (BLOCK BAR (COND ((< A B) (- A B)) (T (+ A B)))) -> :s (COND ((< A B) (- A B)) (T (+ A B))) <=>

(IF (< #:A #:B) (PROGN (- #:A #:B)) (COND (T (+ #:A #:B))))

Page 16: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Step Example Continued (IF (< A B) (PROGN (- A B)) (COND (T (+ A B)))) -> :s (< A B) -> :s A -> :s 3 B -> :s 5 T (PROGN (- A B)) -> :s (- A B) -> :s A -> :s 3 B -> :s 5 -2 -2 -2 -2 -2 -2

By using :si, we can skip a lot of the details

Page 17: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Stepper Commands• :s Step this form and all of its subforms (optional +ve integer arg)• :st Step this form without stepping its subforms• :si Step this form without stepping its arguments if function call• :su Step up out of this form without stepping its subforms• :sr Return a value to use for this form• :sq Quit from the current stepper level• :get <variable> <command identifier>

Get a command from the history list and put it in a variable.• :help Produce this list.• :his &optional <n1> <n2>

List the command history, optionally the last n1 or range n1 to n2.• :redo &optional <command identifier>

Redo a previous command, identified by its number or a substring.• :use <new form> <old form> &optional <command identifier>

Redo command after replacing old form with new form.

Page 18: The Debugger and Inspector Two very useful tools available in Common Lisp are the debugger and inspector –Using them is partially implementation dependent,

Trace Facility• Trace allows you to trace function calls

– (trace functionname) turns trace on• Next time you call functionname, you get to see its behavior – what it

calls, what the parameters are– (untrace functionname) turns trace off

here, fib (the fibonacci function), is called with (fib 4)

0 FIB > ... >> N : 4 1 FIB > ... >> N : 3 2 FIB > ... >> N : 2 2 FIB < ... << VALUE-0 : 1 2 FIB > ... >> N : 1 2 FIB < ... << VALUE-0 : 1

1 FIB < ... << VALUE-0 : 2 1 FIB > ... >> N : 2 1 FIB < ... << VALUE-0 : 10 FIB < ... << VALUE-0 : 33

for more on these facilities, see the LispWorks web site