Helu
You may recall unanswered issues I've raised in the past where incorrect SLIME code crashes CMUCL and buries it in an ldb prompt. I suspect this has not been addressed in the recent overhaul of the communication code and believe bug can be illustrated [in current CVS with the following steps]
In the repl, type
,---- | CL-USER> (inspect (make-instance 'standard-object)) `----
This responds with an assertion failed, in the [possibly buggy] repl code refuses to accept input. Then prints:
,---- | #<STANDARD-OBJECT {5894AE15}> is an instance of #<STANDARD-CLASS STANDARD-OBJECT | {2831D1C5}>. | > `----
At the > prompt enter `q' RET
At the REPL hit C-c 4 times.
Slime loses the connection and CMUCL is dead in ldb>
Is this reproducible by others?
I believe the fix I had suggested earlier would still protect the CMUCL from dying.
-- Madhu
* Madhu [2008-08-22 00:14+0200] writes:
Helu
You may recall unanswered issues I've raised in the past where incorrect SLIME code crashes CMUCL and buries it in an ldb prompt. I suspect this has not been addressed in the recent overhaul of the communication code and believe bug can be illustrated [in current CVS with the following steps]
In the repl, type
,---- | CL-USER> (inspect (make-instance 'standard-object)) `----
This responds with an assertion failed, in the [possibly buggy] repl code refuses to accept input. Then prints:
,---- | #<STANDARD-OBJECT {5894AE15}> is an instance of #<STANDARD-CLASS STANDARD-OBJECT | {2831D1C5}>. | > `----
At the > prompt enter `q' RET
At the REPL hit C-c 4 times.
Slime loses the connection and CMUCL is dead in ldb>
Is this reproducible by others?
Not for me. I don't see failed assertions with 19E-pre2.
Helmut.
* Helmut Eller m2ljyqou4b.fsf@common-lisp.net : Wrote on Fri, 22 Aug 2008 00:56:04 +0200: |> Is this reproducible by others? | | Not for me. I don't see failed assertions with 19E-pre2.
OK. The failed assertion happens on slime checked out on Aug 17. The head ChangeLog entry is
,---- | 2008-08-15 tcr@freebits.de | * slime.el (slime-popup-buffer-quit): Fix regression; we have to... `----
The assertion failure happens on emacs 21.4. 22.2 and 23.0.60
This assertion failure does not happen on slime checked out on Aug 21, which changes the focus behaviour and which has a head ChangeLog entry dated
,---- | 2008-08-18 Helmut Eller heller@common-lisp.net | * swank.lisp (install-fd-handler): Bind *emacs-connection* with... `----
[Note the ChangeLog entries are not in temporal order. the latest ChangeLog entry is a 2008-08-20 which is later in the file. Another reason why reading the file and using this date for versioning slime may not be the best idea]
Now this is only incidental to the problem I wanted to draw attention to. The actual situation is that of CMUCL signalling an unbound variable Q error on a stream already closed on a couple of interrupts.
With slime-2008-08-15, I'm able to reproduce the ldb crash with the scenario upthread on CMUCL "19e (19E)" on emacs 22.2 and 23.0.60 on 32 bit box running CMUCL on a slow processor. The CMUCL version does not matter. However I am NOT able to reproduce the crash on a guest account on a 64bit box running the same CMUCL release. There the connection drops but I'm not dropped into LDB.
I have to dig deeper the next time I encounter this problem -- Madhu
* Madhu m38wupx0ty.fsf@moon.robolove.meer.net : Wrote on Fri, 22 Aug 2008 07:33:53 +0530:
| ,---- | | 2008-08-18 Helmut Eller heller@common-lisp.net | | * swank.lisp (install-fd-handler): Bind *emacs-connection* with... | `---- | | [Note the ChangeLog entries are not in temporal order. the latest | ChangeLog entry is a 2008-08-20 which is later in the file. Another | reason why reading the file and using this date for versioning slime | may not be the best idea]
This is completely wrong. There is no commit on 2008-08-20, and the ChangeLog is in correct order.
Sincerely sorry for the bullshit.
-- Madhu
|* Madhu m38wupx0ty.fsf@moon.robolove.meer.net : |Wrote on Fri, 22 Aug 2008 07:33:53 +0530: | || ,---- || | 2008-08-18 Helmut Eller heller@common-lisp.net || | * swank.lisp (install-fd-handler): Bind *emacs-connection* with... || `----
With SWANK:*COMMUNICATION-STYLE* :fd-handler
With CMUCL 19e (and this version of SLIME, which includes commits from 2008/08/20)
C-u M-x slime /path/to/cmucl/lisp -noinit
M-x slime-disconnect
crashes CMUCL or puts it in an infinite loop, which causes it to grow until it exhausts heap.
Can others reproduce this?
[I believe this is related to the earlier crash, which I am still getting, reproducably]
-- Madhu
* Madhu [2008-08-26 10:07+0200] writes:
With SWANK:*COMMUNICATION-STYLE* :fd-handler
With CMUCL 19e (and this version of SLIME, which includes commits from 2008/08/20)
C-u M-x slime /path/to/cmucl/lisp -noinit
M-x slime-disconnect
crashes CMUCL or puts it in an infinite loop, which causes it to grow until it exhausts heap.
Can others reproduce this?
Yes. Should be fixed in HEAD.
Helmut.
-
Helmut Eller -
Madhu