A demostration of fixing a bug from Medley's debugger
One of the cool features of Lisp is examining and modifying a running program.
This allows, for example, to correct a bug by inspecting, editing, fixing, and resuming a program that breaks and lands in the debugger because of an error. To gain familiarity with the process, I recorded a screencast of a Medley session in which I use the debugger to fix a bug in a running Interlisp function and conclude the computation.
Medley provides advanced debugging facilities and tools in the Break Package, including the Break Window which is the main user interface of the debugger. “Package” as in module or subsystem, not Common Lisp package.
In the recorded session I fix this broken Interlisp function to compute the square of the argument:
(DEFINEQ (CALC.SQUARE (X)
(* Return the square of argument X.)
(TIMES X Y)))
The bug is trivial, a typo. The call to the TIMES multiplication operator passes Y as the second argument instead of the function parameter X.
I begin the recorded session by defining the function with the SEdit Lisp editor. Next, from the Exec (a Lisp REPL) I call the function (CALC.SQUARE 3) and get the error Y is an unbound variable. Then I execute the RETRY Exec command. RETRY evaluates the latest expression and forces entering the debugger if it yields an error.
The topomost few backtrace entries in the Break Window are internal functions called by CALC.SQUARE. From the Break Window's middle-click menu I invoke the REVERT command to move the point of execution back to the CALC.SQUARE call before the error.
This selects the CALC.SQUARE frame where the bug is most likely to be. Inspecting the bindings of the frame provides a clue.
X has the expected value 3 and I confirm it by evaluating X at the debugger REPL. But Y, the variable the error references, doesn't show up in the stack frame. Evaluating Y yields the same error. It's a hint Y shouldn't probably be there and is likely a typo. Therefore, I execute the debugger's EDIT command to open the code of the current function in SEdit. From SEdit I fix the typo and evaluate the modified definition.
The new definition is now in the Lisp image and the current stack frame is still the CALC.SQUARE call in the backtrace. The OK debugger command continues execution from the point of the break, letting the program run the corrected code. The Exec from which I originally called the buggy function finally returns the expected value of the square of 3: 9.
The REVERT, EDIT, and OK commands may be typed at the debugger REPL but I invoked them from the menu to make the menu itself and its options explicit. Similarly, the Done & Close SEdit menu command has the associated keychord C-M-x.
Discuss... Email | Reply @amoroso@fosstodon.org