* Jonathon McKitrick [2006-01-14 08:30+0100] writes:
I've read the links you guys have posted, and I have figured out a lot. But there is one thing yet eluding me. I'm running SLIME with SBCL, and I cannot figure out how to resume execution after breaking into the debugger. I've been able to edit the code, recompile, and restart the whole execution, but actually fixing the code and continuing from that stack frame doesn't seem to work for me yet. When I enter a number 0-9 for the stack frame to resume, SBCL complains by breaking again and telling me I cannot continue from there.
Pressing 0-9 doesn't restart the frame with the corresponding number; it invokes the restart (see CLHS conditions chapter) for that number. E.g. if you call (break), SLIME will display something like this:
Restarts: 0: [CONTINUE] Return from BREAK. 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {AF41B49}>)
Backtrace: 0: (BREAK "break") 1: (SB-INT:EVAL-IN-LEXENV (BREAK) #<NULL-LEXENV>)
Pressing 0 invokes the `continue' restart, which will return from the call to BREAK; it doesn't restart the frame 0.
Restarting a frame (i.e. selecting a frame, unwinding the stack down to that frame, and invoking the corresponding function with the same arguments) isn't implemented for SBCL. I think it works for Lispworks, Allegro, and OpenMCL.
This kind of restarting a frame would be most useful if the program needs to run a long time before the bug is triggered. You could fix the bug and test the fix quickly without having to wait again. If your application never runs for very long, you probably don't miss much if you simply restart from the beginning. Often it's also not necessary to unwind the stack before you can test a fix: you can just call the modified function from within the debugger (if you can figure out the arguments which triggered the bug).
Helmut.