[slime-devel] Debugging without stepping

[Helmut Eller]

* 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.