[slime-devel] CMUCL raises emacs debugger
Hi, If slime-net-coding-system is utf-8-unix, emacs will enter backtrace buffer after cmucl startup. Here is my operation: 1. (setq slime-net-coding-system 'utf-8-unix) 2. C-u M-x slime 3. input "lisp -noinit" 4. cmucl starting... 5. cmucl started, but raises emacs debugger This error doesn't occur every time. If everything is ok, please quit cmucl then restart it, the error should occur now. I'm on debian sid, but use upstream slime and cmucl (unicode version). Thanks, Des
On 3/3/11 7:47 AM, Desmond O. Chang wrote:
Hi,
If slime-net-coding-system is utf-8-unix, emacs will enter backtrace buffer after cmucl startup. Here is my operation:
1. (setq slime-net-coding-system 'utf-8-unix) 2. C-u M-x slime 3. input "lisp -noinit" 4. cmucl starting... 5. cmucl started, but raises emacs debugger
This error doesn't occur every time. If everything is ok, please quit cmucl then restart it, the error should occur now.
FWIW, I can reproduce this. I don't have such problems with cmucl and xemacs, though. I don't what the cause is, but a backtrace would be useful. Ray Debugger entered--Lisp error: (cl-assertion-failed (plusp length)) (condition-case error (slime-net-read) (error (debug ... error) (slime-net-close process t) (error "net-read error: %S" error))) slime-net-read-or-lose(#<process SLIME Lisp>) slime-process-available-input(#<process SLIME Lisp>) slime-net-filter(#<process SLIME Lisp> "00034B(:return (:ok (:pid 67280 :style :fd-handler :encoding (:coding-system \"utf-8-unix\" :external-format \"UTF-8\") :lisp-implementation (:type \"CMU Common Lisp\" :name \"cmucl\" :version \"Snapshot 2011-03 (20B Unicode)\" :program \"/Volumes/share2/darwin10.6/lib/cm$ recursive-edit() byte-code("\306^P @\307=\203!^@\310\311\312\"\210\313\311!\211^ZA@)\242\314=\203!^@\310\315\312\"\210\316^K!\210\317 \210\320 !\210\f\203c^@\321ed\"^MV\203W^@eb\210\322^M\245y\210`^^^[db\210\322^M\245^MZy\210^N^[`|\210)\323c\210eb\210\324\325\326 \"\210\327 \210\324\330!\210\331\312^^^\^^^]\324\330!\210$ debug(error (cl-assertion-failed (plusp length))) (condition-case error (slime-net-read) (error (debug ... error) (slime-net-close process t) (error "net-read error: %S" error))) slime-net-read-or-lose(#<process SLIME Lisp>) slime-process-available-input(#<process SLIME Lisp>) slime-net-filter(#<process SLIME Lisp> "D97(:indentation-update ((\"with-symbol\" . 1) (\"with-read-buffer\" . 1) (\"enumerate-matches\" . 1) (\"prepare-for-fast-read-byte\" . 1) (\"maybe-sap-maybe-string\" . 1) (\"def-output-routines\" . 1) (\"prepare-for-fast-read-char\" . 1) (\"with-host\" . 1) (\"with-pathn$ recursive-edit() byte-code("\306^P @\307=\203!^@\310\311\312\"\210\313\311!\211^ZA@)\242\314=\203!^@\310\315\312\"\210\316^K!\210\317 \210\320 !\210\f\203c^@\321ed\"^MV\203W^@eb\210\322^M\245y\210`^^^[db\210\322^M\245^MZy\210^N^[`|\210)\323c\210eb\210\324\325\326 \"\210\327 \210\324\330!\210\331\312^^^\^^^]\324\330!\210$ debug(error (cl-assertion-failed (plusp length))) (condition-case error (slime-net-read) (error (debug ... error) (slime-net-close process t) (error "net-read error: %S" error))) slime-net-read-or-lose(#<process SLIME Lisp>) slime-process-available-input(#<process SLIME Lisp>) slime-net-filter(#<process SLIME Lisp> "000064(:background-message \"[GC done. 10.6 MB freed 3.9 MB retained 0.0/1.0/0.0/0.0/0.0/0.0 0.02 sec]\")") recursive-edit() byte-code("\306^P @\307=\203!^@\310\311\312\"\210\313\311!\211^ZA@)\242\314=\203!^@\310\315\312\"\210\316^K!\210\317 \210\320 !\210\f\203c^@\321ed\"^MV\203W^@eb\210\322^M\245y\210`^^^[db\210\322^M\245^MZy\210^N^[`|\210)\323c\210eb\210\324\325\326 \"\210\327 \210\324\330!\210\331\312^^^\^^^]\324\330!\210$ debug(error (cl-assertion-failed (plusp length))) (condition-case error (slime-net-read) (error (debug ... error) (slime-net-close process t) (error "net-read error: %S" error))) slime-net-read-or-lose(#<process SLIME Lisp>) slime-process-available-input(#<process SLIME Lisp>) slime-net-filter(#<process SLIME Lisp> "00000003C(:background-message \"[Commencing GC with 14.5 MB in use.]\")")
* Raymond Toy [2011-03-03 20:26] writes:
On 3/3/11 7:47 AM, Desmond O. Chang wrote:
Hi,
If slime-net-coding-system is utf-8-unix, emacs will enter backtrace buffer after cmucl startup. Here is my operation:
1. (setq slime-net-coding-system 'utf-8-unix) 2. C-u M-x slime 3. input "lisp -noinit" 4. cmucl starting... 5. cmucl started, but raises emacs debugger
This error doesn't occur every time. If everything is ok, please quit cmucl then restart it, the error should occur now.
FWIW, I can reproduce this. I don't have such problems with cmucl and xemacs, though. I don't what the cause is, but a backtrace would be useful.
The problem seems to be that (format stream "~6,'0x" length) triggers a gc-hook which writes something to the stream in the middle of the length field. I was able to reproduce it with the March snapshot but not with the one from December. Quick workaround: add (setq swank-backend::*install-gc-hooks* nil) to ~/.swank.lisp. We could write the length to a private buffer before writing it to the stream. That would probably work most of the time. I guess, tho, that any kind of writing to a stream can potentially trigger gc. Helmut
On 3/4/11 3:00 AM, Helmut Eller wrote:
* Raymond Toy [2011-03-03 20:26] writes:
On 3/3/11 7:47 AM, Desmond O. Chang wrote:
Hi,
If slime-net-coding-system is utf-8-unix, emacs will enter backtrace buffer after cmucl startup. Here is my operation:
1. (setq slime-net-coding-system 'utf-8-unix) 2. C-u M-x slime 3. input "lisp -noinit" 4. cmucl starting... 5. cmucl started, but raises emacs debugger
This error doesn't occur every time. If everything is ok, please quit cmucl then restart it, the error should occur now.
FWIW, I can reproduce this. I don't have such problems with cmucl and xemacs, though. I don't what the cause is, but a backtrace would be useful.
The problem seems to be that (format stream "~6,'0x" length) triggers a gc-hook which writes something to the stream in the middle of the length field. I was able to reproduce it with the March snapshot but not with the one from December.
Quick workaround: add (setq swank-backend::*install-gc-hooks* nil) to ~/.swank.lisp.
We could write the length to a private buffer before writing it to the stream. That would probably work most of the time. I guess, tho, that any kind of writing to a stream can potentially trigger gc.
How about disabling gc in write-message? Or at least on cmucl, binding ext:*gc-verbose* to NIL in write-message? That seems to work for me. Ray
participants (3)
-
Desmond O. Chang -
Helmut Eller -
Raymond Toy