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> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366> :USER-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> :USER-IO #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366>, output #<TCP-STREAM (SOCKET/20) #x6C76756> #x6C76326> :CONTROL-THREAD #<PROCESS control-thread(3) [Active] #x6C76166> :READER-THREAD #<PROCESS reader-thread(4) [Active] #x6C75F66> :REPL-THREAD #<PROCESS repl-thread(5) [Active] #x6C75D6E> :READ #<Compiled-function SWANK::READ-FROM-CONTROL-THREAD #x6C2DCC6> :SEND #<Compiled-function SWANK::SEND-TO-CONTROL-THREAD #x6C2B1BE> :SERVE-REQUESTS #<Compiled-function SWANK::SPAWN-THREADS-FOR-CONNECTION #x6C1FE16> :CLEANUP NIL :INDENTATION-CACHE #<HASH-TABLE :TEST EQ size 60/60 #x6C768E6> :INDENTATION-CACHE-PACKAGES (#<Package "ASDF1017"> #<Package "ASDF945"> #<Package "ASDF-INSTALL-CUSTOMIZE"> #<Package "ASDF-INSTALL"> #<Package "ASDF-INSTALL-SYSTEM"> #<Package "ASDF942"> #<Package "SWANK-COMPLETION-TEST"> #<Package "SWANK-IO-PACKAGE"> #<Package "SWANK"> #<Package "NREGEX"> #<Package "SWANK-BACKEND"> #<Package "SWANK-LOADER"> #<Package "ASDF"> #<Package "CROSS-REFERENCE"> #<Package "PPC64"> #<Package "PPC"> #<Package "PPC32"> #<Package "ILISP"> #<Package "OPENMCL-MOP"> #<Package "GRAY"> #<Package "CLOS-BOOT"> #<Package "OPENMCL-SOCKET"> #<Package "INSPECTOR"> #<Package "OS"> #<Package "ARCH"> #<Package "ANSI-LOOP"> #<Package "COMMON-LISP-USER"> #<Package "SETF"> #<Package "CCL"> #<Package "COMMON-LISP"> #<Package "KEYWORD">)))") (2 "(RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (3 "((:LAMBDA 1 :IN %PROCESS-PRESET-INTERNAL) '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (4 "((:LAMBDA 1 :IN THREAD-MAKE-STARTUP-FUNCTION))"))) .
While executing: FUNCALL
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.
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
3) CCL::%%FRAME-BACKLINK periodically hard crashes the lisp. I'll send the kernel debugger backtrace next time it happens
4) Typically after a very large amount of output to the repl, slime space starts infinite looping in emacs and I have to interrupt it with control-g (after I type each space). Needless to say, I restart as soon as I can.
So things are a bit of a mess and I would spend some time looking into it but have been flat out recently. But maybe this will give someone a hint about what is going on. And I should start having some more time in a couple of weeks.
-Alan
On Jun 11, 2004, at 4:25 PM, Gary Byers wrote:
On Fri, 11 Jun 2004, Christian Hofer wrote:
Hi,
when I'm working with OpenMCL on Darwin, and SLIME, I just cannot figure out, how to use the debugger correctly. I just downloaded the newest OpenMCL release and the newest SLIME tarball, and the behaviour is getting even worse.
E.g. when I try to evaluate the variable test in the listener, I get - as expected - the following error:
Unbound variable: TEST [Condition of type UNBOUND-VARIABLE]
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]
When I try, on the other hand option 4 or 5, the listener seems to loose contact to OpenMCL.
SBCL on FreeBSD behaves completely different and I did not encounter any similiar problems.
Thus I wanted to know, if the lost connection is expected behaviour. And on the other hand, if I did s.th. wrong during installation or if simple-restart does not work at the moment?
CCL::SIMPLE-RESTART isn't a function (it -is- the name of a type of restart), so if something's calling it as a function it's not too surprising that it's undefined. If something's trying to call it as a function, there would probably have been undefined-function warnings during compilation; you might want to look at the *INFERIOR-LISP* buffer to see if it shows any evidence of this.
I tried to reproduce this with the current SLIME from CVS; I found that restarts 0-2 worked as expected in this case; 3-5 seemed to all lose the connection, with messages in the *INFERIOR-LISP* buffer to the effect that some socket used to communicate between Emacs and the lisp had received an unexpected EOF. The thread that's running the SLIME REPL seems to be in:
(defimplementation receive () (let* ((mbox (mailbox ccl:*current-process*)) (mutex (mailbox.mutex mbox))) (ccl:wait-on-semaphore (mailbox.semaphore mbox)) (ccl:with-lock-grabbed (mutex) (pop (mailbox.queue mbox)))))
waiting on a semaphore that'll probably never be signalled (I don't know much about the protocol SLIME/SWANK use, but I'd guess that the unexpected EOF has something to do with this ...
Sorry that's not more helpful.
Thanks, Chris
Openmcl-devel mailing list Openmcl-devel@clozure.com http://clozure.com/mailman/listinfo/openmcl-devel
Openmcl-devel mailing list Openmcl-devel@clozure.com http://clozure.com/mailman/listinfo/openmcl-devel
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.
-
Alan Ruttenberg -
Helmut Eller