[Openmcl-devel] Problems with the SLIME debugger
Alan Ruttenberg
alanr-l at mumble.net
Fri Jun 11 23:09:45 PDT 2004
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 at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
More information about the Openmcl-devel
mailing list