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

Sat Jun 12 06:09:45 UTC 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