[slime-devel] Re: [Openmcl-devel] Problems with the SLIME debugger

[Helmut Eller]

I don't know what is causing the problems; I can only make some
remarks.

Alan Ruttenberg <alanr-l at mumble.net> writes:

> I'm having a few problems as well and have been really wanting to sit
> down and document and try to untangle them. I think a couple of
> messages to slime-devel got lost in the down time.
>
> 1)
> I get this periodically in the inferior lisp, when running slime in
> openmcl.
>
>  > Error in process control-thread(3): Undefined function :DEBUG
> called with arguments (#<PROCESS control-thread(3) [Active] #x6C76166>
> 1 ("destructure-case failed: NIL" "   [Condition of type
> SIMPLE-ERROR]") (("ABORT" "Restart dispatch loop.") ("ABORT-BREAK"
> "#<RESTART ABORT-BREAK #x7FEE06>") ("ABORT" "#<RESTART ABORT
> #x7FEE2E>")) ((0 "(SWANK::DISPATCH-EVENT #<TCP-STREAM (SOCKET/19)
> #x6C76EBE>)") (1 "(SWANK::DISPATCH-LOOP #<TCP-STREAM (SOCKET/19)
> #x6C76EBE> #S(SWANK::CONNECTION :SOCKET-IO #<TCP-STREAM (SOCKET/19)
> #x6C76EBE> :DEDICATED-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> 
[...]
>  > While executing: FUNCALL

A few things are strange here.  First, DISPATCH-EVENT is apparently
called with a NIL event; that's not normal.  Second, the backtrace

 (0 "(SWANK::DISPATCH-EVENT #<TCP-STREAM (SOCKET/19) #x6C76EBE>)")

doesn't show the first argument, only the second.  Third, the control
thread seems to call swank-debugger-hook -> debug-in-emacs ->
sldb-loop and tries to invoke the Emacs debugger by sending a :debug
event to itself; bugs in the control thread should invoke the tty
debugger, because *debugger-hook* is usually nil in the control
thread.  Fourth, the :debug event is apparently funcalled/evaled.

> It's usually impossible to recover once this starts happening. It's as
> if the :emacs-rex if being left off the car of all the messages.

A bug in the control thread can usually be recovered by invoking the
"Restart dispatch loop." restart in the *inferior-lisp* buffer.  Such
bugs are of course rather serious and should be fixed.

> 2)
> In openmcl.
> Traced send and receive. These receives don't seem to be initiated by
> a send...
> They happen now and then when loading a system that takes a while to
> load (probably other times too).
> Ignoring them prevents my lisp from being hosed. If you already know
> what the problem is, send me a note, otherwise
> I will continue looking when I have a chance.
>
>   Calling (SWANK-BACKEND:RECEIVE)
>   SWANK-BACKEND:RECEIVE returned NIL
> DISPATCHING: NIL
> IGNORING UNKNOWN EVENT: NIL
>   Calling (SWANK-BACKEND:RECEIVE)
>   SWANK-BACKEND:RECEIVE returned NIL
> DISPATCHING: NIL
> IGNORING UNKNOWN EVENT: NIL
>   Calling (SWANK-BACKEND:RECEIVE)
>   SWANK-BACKEND:RECEIVE returned NIL
> DISPATCHING: NIL
> IGNORING UNKNOWN EVENT: NIL

We never SEND NIL as message and hence RECEIVE should never return
NIL.  All our events look like '(keyword arg...).  I added some
assertions to make this more explicit.


>>> Restarts:
>>>    0: [CONTINUE] Retry getting the value of TEST.
>>>    1: [USE-VALUE] Specify a value of TEST to use this time.
>>>    2: [STORE-VALUE] Specify a value of TEST to store and use.
>>>    3: [ABORT] Abort handling SLIME request.
>>>    4: [ABORT-BREAK] #<RESTART ABORT-BREAK #x1692E06>
>>>    5: [ABORT] #<RESTART ABORT #x1692E2E>
>>>
>>> Now, none of the aborts seem to work properly. When I chose 3, I get
>>> the following error:
>>>
>>> Undefined function CCL::SIMPLE-RESTART called with arguments () .
>>>     [Condition of type CCL::UNDEFINED-FUNCTION-CALL]

Don't know what's causing this problem.

>>> When I try, on the other hand option 4 or 5, the listener seems to
>>> loose contact to OpenMCL.

I think this is expected.  4 and 5 cause the REPL thread to terminate;
those restarts should probably be hidden, but so far nobody cared.

>>> SBCL on FreeBSD behaves completely different and I did not encounter
>>> any similiar problems.

SBCL/FreeBSD doesn't use threads; it behaves differently and has it's
own set of problems.

Helmut.