[slime-devel] SBCL, multiple (zombie?) processes problems
I'm finding that if I try to run SLIME with SBCL on my debian machine, that multiple sbcl processes (4) start, and if I immediately type (quit) at the REPL, only one of the four is killed. If I instead go into *inferior-lisp* and type (quit), it quit's out of all 4. If I quit the REPL one first, then go to *inferior-lisp*, I get errors like "interrupt thread 6376 failed (3: No such process). This seems to indicate to me some bad interaction between SBCL threads/processes and SLIME? I wouldn't care that much about the zombies, but my XML-RPC server is also not working in SLIME (calls to it hang forever, works fine if I start sbcl in a shell), and I suspect the difficulties are related. Any thoughts? This seems to be an issue with both the current SLIME (CVS today) and the 1.0 tarball (I tried switching to the 1.0 tarball by deleting both the old SLIME directory and my .slime directory --- is anything else necessary)? Cheers, rif
On Mon, 13 Sep 2004, rif wrote:
I'm finding that if I try to run SLIME with SBCL on my debian machine, that multiple sbcl processes (4) start, and if I immediately type (quit) at the REPL, only one of the four is killed. If I instead go into *inferior-lisp* and type (quit), it quit's out of all 4. If I quit the REPL one first, then go to *inferior-lisp*, I get errors like "interrupt thread 6376 failed (3: No such process). This seems to indicate to me some bad interaction between SBCL threads/processes and SLIME?
I don't think this is a Slime issue at all, but purely an SBCL one. The first two case (killing one vs. killing all) is as it should be as far as I know: quitting a child doesn't affect the parent, killing the parent kills the children as well. As for the errors, I'm not sure, but I think something was done about this recently: what version of SBCL is this?
I wouldn't care that much about the zombies, but my XML-RPC server is also not working in SLIME (calls to it hang forever, works fine if I start sbcl in a shell), and I suspect the difficulties are related.
Always a possibility, but I suspect they're not related; this latter one is as you say probably a Slime / SBCL interaction problem. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
On Mon, 13 Sep 2004, rif wrote:
I'm finding that if I try to run SLIME with SBCL on my debian machine, that multiple sbcl processes (4) start, and if I immediately type (quit) at the REPL, only one of the four is killed. If I instead go into *inferior-lisp* and type (quit), it quit's out of all 4. If I quit the REPL one first, then go to *inferior-lisp*, I get errors like "interrupt thread 6376 failed (3: No such process). This seems to indicate to me some bad interaction between SBCL threads/processes and SLIME?
I don't think this is a Slime issue at all, but purely an SBCL one. The first two case (killing one vs. killing all) is as it should be as far as I know: quitting a child doesn't affect the parent, killing the parent kills the children as well.
If I start sbcl at a prompt, it starts only one process. If I quit, it vanishes. If I start sbcl from slime, I get four processes. This is why I said it seems to be an SBCL/SLIME interaction issue --- I have no way to reproduce any of this undesirable behavior without SLIME. The SBCL version is 0.8.14 (debian version 0.8.14-2). rif
On Mon, 13 Sep 2004, rif wrote:
If I start sbcl at a prompt, it starts only one process. If I quit, it vanishes. If I start sbcl from slime, I get four processes. This is why I said it seems to be an SBCL/SLIME interaction issue --- I have no way to reproduce any of this undesirable behavior without SLIME.
Fair enough, in that sense it is a Slime issue: you're not using multiple threads when you start SBCL from shell, but apparently you're using :spawn for Slime. Try :fd-handler or :sigio instead. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Fair enough, in that sense it is a Slime issue: you're not using multiple threads when you start SBCL from shell, but apparently you're using :spawn for Slime. Try :fd-handler or :sigio instead.
Yeah, I could. I have this all working on another machine, but it's using a different version of sbcl 0.8.17, and it seems that these problems crop up on 0.8.14 and later. I just installed sbcl 0.8.17 from debian unstable, and now SLIME won't even compile --- I get a type error when it tries to compile DEFMETHOD INSPECTED-PARTS. rif
I'm getting more and more confused. I have two debian machines, both running 2.6 kernels, both running the same version of SLIME, the same version of sbcl, using the exact same .emacs. On one machine, sbcl only ever starts one process when started on slime, on the other it starts four. Any ideas what else to check? rif
On Mon, 13 Sep 2004, rif wrote:
I'm getting more and more confused. I have two debian machines, both running 2.6 kernels, both running the same version of SLIME, the same version of sbcl, using the exact same .emacs. On one machine, sbcl only ever starts one process when started on slime, on the other it starts four. Any ideas what else to check?
Are they using the same .swank.lisp? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
On Mon, 13 Sep 2004, rif wrote:
I'm getting more and more confused. I have two debian machines, both running 2.6 kernels, both running the same version of SLIME, the same version of sbcl, using the exact same .emacs. On one machine, sbcl only ever starts one process when started on slime, on the other it starts four. Any ideas what else to check?
Are they using the same .swank.lisp?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Well, on the working machine there was a .swank.lisp explicitly setting the communication style to :fd-handler, which I believe is the default; both machines were using :fd-handler. Switching the "bad machine" to :sigio eliminated the problem, but this still leaves the question of why it didn't work with :fd-handler on that machine when it did on another machine with the same slime and SBCL and an identical .emacs. At this point, I have something working, so it's not crucial, but it's still troubling. Cheers, rif
I posted this issue, along with a patch, the first of August. Luke Gorrie replied:
The fix looks right, but it's not working for me. Actually I seem to be having some weird problems reconnecting to SBCL when running `M-x slime' repeatedly.
Thanks for the patch, I'll need to investigate the weirdness a bit before applying.
Unfortunately I was stupid and forgot to put the patch in unidiff format, and I think it fell through the cracks. Someone said they thought the issue was fixed in a recent version of SBCL, but I've just tested Slime 1.0 with SBCL 0.8.14 on Slackware 10.0, and the issue still exists. My (now unidiff) patch was made against slime-1.0beta, but it still seems to fix the problem. The patch is included below. -A Maxint Consulting Linux: The ultimate video game. Common subdirectories: slime-1.0beta/doc and lib/emacs/slime-1.0beta/doc diff -u slime-1.0beta/swank.lisp lib/emacs/slime-1.0beta/swank.lisp --- slime-1.0beta/swank.lisp Tue Aug 3 06:39:02 2004 +++ lib/emacs/slime-1.0beta/swank.lisp Wed Aug 4 23:21:57 2004 @@ -504,6 +504,10 @@ (setf (connection.repl-thread connection) repl-thread) connection))) +(defun cleanup-connection-threads (connection) + (kill-thread (connection.control-thread connection)) + (kill-thread (connection.repl-thread connection))) + (defun repl-loop (connection) (with-connection (connection) (loop (handle-request connection)))) @@ -610,7 +614,8 @@ (make-connection :socket-io socket-io :read #'read-from-control-thread :send #'send-to-control-thread - :serve-requests #'spawn-threads-for-connection)) + :serve-requests #'spawn-threads-for-connection + :cleanup #'cleanup-connection-threads)) (:sigio (make-connection :socket-io socket-io :read #'read-from-socket-io Only in lib/emacs/slime-1.0beta: swank.lisp~
Alan Caulkins <fatman@maxint.net> writes:
I posted this issue, along with a patch, the first of August. Luke Gorrie replied:
Oops! Lost track of that while changing mail hosts, losing all my Gnus folder 'ticks' (sorry everyone :-). Applied now, though today I didn't test it because I don't have SBCL handy and I'm on a slow computer. -Luke
rif <rif@MIT.EDU> writes:
Well, on the working machine there was a .swank.lisp explicitly setting the communication style to :fd-handler, which I believe is the default; both machines were using :fd-handler.
On SBCL with #+(and SB-THREAD SB-FUTEX) the default is actually :SPAWN.
rif <rif@MIT.EDU> writes:
Fair enough, in that sense it is a Slime issue: you're not using multiple threads when you start SBCL from shell, but apparently you're using :spawn for Slime. Try :fd-handler or :sigio instead.
Yeah, I could. I have this all working on another machine, but it's using a different version of sbcl 0.8.17, and it seems that these problems crop up on 0.8.14 and later. I just installed sbcl 0.8.17 from debian unstable, and now SLIME won't even compile --- I get a type error when it tries to compile DEFMETHOD INSPECTED-PARTS. Well whatever that is it could not be 0.8.17, my version is from CVS and I have update it yesterday and it is verson 0.8.14.13 (quite a lot of numbers;-) However I'm not able to compile swank any longer therfor my questoin if someone else has encountered problems.
Your mail suggested that I'm not alone with the problems....
On Tue, 14 Sep 2004, Friedrich Dominicus wrote:
Well whatever that is it could not be 0.8.17, my version is from CVS and I have update it yesterday and it is verson 0.8.14.13 (quite a lot of numbers;-) However I'm not able to compile swank any longer therfor my questoin if someone else has encountered problems.
Your mail suggested that I'm not alone with the problems....
Yes, you're not. SBCLs 0.8.14.13 - 0.8.14.18 are broken vrt. Slime (or anything else that tickles certain code paths, for that matter). Happily the issue was fixed by Alexey Dejneka in 0.8.14.19 -- which should appear soonish in anoncvs. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
rif <rif@MIT.EDU> writes:
I just installed sbcl 0.8.17 from debian unstable, and now SLIME won't even compile --- I get a type error when it tries to compile DEFMETHOD INSPECTED-PARTS.
do you still have this issue? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
participants (6)
-
Alan Caulkins -
Friedrich Dominicus -
Luke Gorrie -
Marco Baringer -
Nikodemus Siivola -
rif