From: Andreas F. <as...@bo...> - 2005-07-12 11:03:31
|
Recently, I discovered a very strange problem: When I run M-x slime RET with recent SBCLs starting from 0.9.2.9 (G=E1bor Melis' thread objects change), I get random crashes (emacs calls them "hangups") when using SBCL and the :SPAWN communication-style. In fact, every SBCL session running SLIME which outputs directly to an emacs buffer dies - I just tried running SBCL, then a swank server in M-x terminal-emulator RET. Running swank in SBCL with stdout/stderr tee(1)ed into both a file and into the emacs buffer gives me no such failures. This is problem has the same symptoms as the one I reported on the slime-devel list (in http://article.gmane.org/gmane.lisp.slime.devel/3715). One difference though is that I'm running a slime with the patch that's supposed to fix it. Still, this is what's happening: Using (setq inferior-lisp-program "sbcl --noinform --userinit /dev/null --sysinit= /dev/null") and executing M-x slime RET makes the slime session crash -- the SBCL running in *inferior-lisp* dies. But using (setq inferior-lisp-program "/home/asf/bin/start-sbcl.sh") with start-sbcl.sh being: #!/bin/sh /home/asf/bin/sbcl --noinform --userinit /dev/null --sysinit /dev/null 2>&1= | tee ~/sbcl-typescript and executing M-x slime RET gives me a working slime session; no crashes at all. Running a swank server (with the same SBCL) in a terminal or in screen and connecting to that works, as well. The failing sessions have another interesting property: The hangups seem to occur at random times. Sometimes, I get a *slime-repl* buffer, sometimes SBCL dies with only the *inferior-lisp* buffer showing the hangup message. Some failures leave the *inferior-lisp* buffer looking like this: http://paste.lisp.org/display/9821 (leaving output seemingly unflushed). Some failures display the *log-events* output just fine; no error message is ever displayed, other than "Process inferior-lisp hangup". G=E1bor Melis helped me debug this on #lisp yesterday, in the discussion starting at <http://meme.b9.com/cview.html?channel=3Dlisp&utime=3D3330090675#utime_requ= ested>. We reached no conclusion on what the problem could be. I tried this on emacs multi-tty 22.0.50.1, on debian sid's emacs21-x 21.4.1 and on debian sid's XEmacs 21.4 (patch 17). All showed the behavior described above. The reason for this breakage completely eludes me. It also seems that I'm the only person experiencing this failure and SLIME works for everybody else in the same setup. )-: Does anyone of the SBCL gurus have an idea what could be wrong? Cheers, --=20 Andreas Fuchs, <as...@bo...>, as...@ja..., antifuchs |
From: <me...@ho...> - 2005-07-13 10:31:30
|
On Tuesday 12 July 2005 13:03, Andreas Fuchs wrote: > Recently, I discovered a very strange problem: When I run M-x slime > RET with recent SBCLs starting from 0.9.2.9 (G=E1bor Melis' thread > objects change), I get random crashes (emacs calls them "hangups") > when using SBCL and the :SPAWN communication-style. In fact, every > SBCL session running SLIME which outputs directly to an emacs buffer > dies - I just tried running SBCL, then a swank server in M-x > terminal-emulator RET. Running swank in SBCL with stdout/stderr > tee(1)ed into both a file and into the emacs buffer gives me no such > failures. > As Andreas have since confirmed it is there since pthread merge. The immediate cause is emacs sending a SIGHUP to sbcl that does not have a= =20 handler and promptly exits which is the right behaviour. My tests showed th= at=20 even if :sigio or :fd-handler is used, the first thread exit makes emacs se= nd=20 sighup. A possible workaround is: (setq inferior-lisp-program "nohup sbcl") or writing a little wrapper script around sbcl if you want *inferior-lisp*= =20 keep its sanity. But probably it is a kernel problem after all: for me the problem went away= =20 after a 2.6.8 -> 2.6.11 upgrade. Cheers, G=E1bor |