[slime-devel] Re: basic sldb question

[Helmut Eller]

* Stever [2008-07-13 05:21+0200] writes:

> I am teaching myself lisp, but sometimes I like to step through other
> people's code using a debugger. I'm trying to figure out how the sldb
> debugger works in slime, but I am having trouble doing so. The
> documentation here:
> http://common-lisp.net/project/slime/doc/html/Examining-frames.html#Examining-frames
> talks about "frames". Ummm, what's a frame? 

A frame (sometimes called stack-frame, or activation record) contains
the information--return address, values of variables etc.--that the Lisp
system stores on the stack before a function call, i.e. the information
that is needed after the call returns.  In the debugger, there's one
frame for each active call.  The "backtrace" or "stacktrace" is the list
of frames.  Debuggers for languages like C/Java/Python also have frames;
it's not a Lisp specific concept.

While the backtrace only contains the information needed to continue
after a call, it's often convenient to think of it as a snapshot of the
stack before the call.  That's what makes backtraces so useful for
debugging.

> How do I stop execution of code in slime/emacs 

There are a few different ways stop execution:

1) insert a (break) call at the place where you want to stop.  BREAK
just invokes the debugger.  (Of course, just inserting the text
"(break)" isn't enough, you also must recompile the function.)

2) if you want to debug an endless loop or some lengthy computation you
can use the interrupt command C-c C-b (or C-c C-c in the repl buffer).

3) just run your program and wait until it signals an error.  If the
error isn't handled by your program the Lisp system will invoke the
debugger instead.

SLIME has no commands to set/delete breakpoints.  Variant 3) is the most
effective for easy fixable bugs, like calling undefined functions,
wrong number of arguments etc.

> and run each line one by one?

Stepping isn't so easy.  Few Lisp's support stepping line-by-line.  With
SBCL you can step "sexp-by-sexp" with the sldb-next command (bound to
x), if you compiled your code with high debug settings.  With CMUCL you
can step at basic-block level with the sldb-step command (bound to s).
Allegro CL supports instruction level stepping but SLIME has no commands
for that.  Stepping in SLIME is rather experimental (since 5 years or so
:) and there are probably serious bugs.

The SLIME debugger is useful to quickly find out where the problem
occurred (show-source command) and to see example values (show local
variables) that triggered the bug.  This is often all you need to fix a
bug, but for harder cases it's usually more effective to insert print
statements.

Helmut.