I'm using SLIME to debug my Common Lisp function. Inside the function, I've made it artificially signal an error (trying to "debug"—perhaps I should be stepping) like so:
(define-condition unknown-zone (error)
((text :initarg :text :reader text)))
(defun parse-mime-date (date)
(let ((last-space (position #\Space date :from-end t)))
(let ((date-time (net.telent.date:parse-time (subseq date 0 last-space)))
(zone (subseq date (1+ last-space))))
(unless (or (char= (elt zone 0) #\+)
(char= (elt zone 0) #\-))
(error 'unknown-zone :text (format nil "Unknown timezone: ~a" zone)))
(let ((hours (parse-integer (subseq zone 0 3)))
(minutes (parse-integer
(concatenate 'string
(list (elt zone 0))
(subseq zone 3)))))
(error 'unknown-zone :text "LOL")
(let ((adjusted-date-time (- date-time (* 60 (+ minutes (* 60 hours))))))
(format t "date-time: ~a; zone: ~a~%" date-time zone)
(format t "adjusted: ~a" (net.telent.date:universal-time-to-http-date adjusted-date-time)))))))
I'm trying to work around what appears to be a deficiency in net.telent.date:parse-time
(it seems to botch up timezone handling, though I'm not 100% yet).
The "LOL" unknown-zone
error is of course the artificial breakpoint.
When it hits this part of the function, SLDB faithfully opens up with the backtrace:
Bad type argument:
NS-MAIL2ZD::UNKNOWN-ZONE
[Condition of type SIMPLE-TYPE-ERROR]
Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 7: #<CLOSURE (LABELS SWANK-BACKEND::RUN :IN SWANK-BACKEND:ADD-FD-HANDLER) {10030AD9FB}>>
3: [ABORT] Exit debugger, returning to top level.
Backtrace:
0: (MAKE-CONDITION NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
1: (ERROR NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
2: (NS-MAIL2ZD:PARSE-MIME-DATE "Wed, 14 Mar 2012 06:59:36 +1100")
3: (SB-INT:SIMPLE-EVAL-IN-LEXENV (NS-MAIL2ZD:PARSE-MIME-DATE *LOL*) #<NULL-LEXENV>)
4: (EVAL (NS-MAIL2ZD:PARSE-MIME-DATE *LOL*))
--more--
Then I page down to the frame:
Backtrace:
0: (MAKE-CONDITION NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
1: (ERROR NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
Locals:
SB-KERNEL::ARGUMENTS = (:TEXT "LOL")
SB-KERNEL::DATUM = NS-MAIL2ZD::UNKNOWN-ZONE
2: (NS-MAIL2ZD:PARSE-MIME-DATE "Wed, 14 Mar 2012 06:59:36 +1100")
Now I hit e to invoke sldb-eval-in-frame
and type last-space
, as that should be available where the error was signaled.
It seems this isn't how it's meant (?) to work:
The variable LAST-SPACE is unbound.
[Condition of type UNBOUND-VARIABLE]
Restarts:
0: [ABORT] Return to sldb level 1.
1: [RETRY] Retry SLIME REPL evaluation request.
2: [*ABORT] Return to SLIME's top level.
3: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 7: #<CLOSURE (LABELS SWANK-BACKEND::RUN :IN SWANK-BACKEND:ADD-FD-HANDLER) {10030AD9FB}>>
4: [ABORT] Exit debugger, returning to top level.
Backtrace:
0: ((LAMBDA (#:G1144)) #<unavailable argument>)
--more--
Is there a way to do what I want? Am I over-complicating matters?
Thanks!
Addendum: I've tried using (break)
(this seems a tad more canonical), but I still can't see let
-bound variables with e. :<
Try using the complete name of the symbol (i.e. package::symbol-name
) instead of just the symbol name (i.e. symbol-name
). In the current case, maybe net.telent.date::last-space
.
Also make sure that you compiled with debugging support set to maximum (for instance, try placing a (declaim (optimize debug))
before your function and recompile the file - C-c C-k).
Checking that the code you're trying to debug has enough debug information: in the sldb window, put the cursor on the relevant line in the backtrace and press t - this should expand the frame and show values for all the locals. Pressing t again collapses the local frame information. If there is not enough debug information, you won't see the local variables, but some made up names (such as SB-DEBUG:ARG-0
under SBCL). Inside the sldb window, if you press Enter with the cursor on a value, it will expand that value into an inspector window (useful if the value is a long list which is shown truncated).
Also, SLIME debugging support seems to vary with the implementation. The advice above works on SBCL under Linux, YMMV under different implementations.