I don't know what is causing the problems; I can only make some remarks.
Alan Ruttenberg alanr-l@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.
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.
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.