[slime-devel] Hints needed on why "Process inferior-lisp hangup" occurs
I need some hints to start figuring out why I regularly get a "Process inferior-lisp hangup" in my *inferior-lisp* buffer, but I do not have clue where to start. Situation: * OS: Mac OS X * Lisp version: sbcl 64bit 1.0.28 and ccl 1.3-r12156M (64bit) * Slime version: CVS version as of today. "Reproduction Scenario" 1 Start slime with one of the two lisp implementaitons mentioned above 2 Open "/dev/tty.NXT-DevB-1", which is a serial blue tooth connection to a Lego NXT brick. 3 Turn of the Lego NXT brick (the other side of the serial connection) After this, I get the "Process inferior-lisp hangup" in the *inferior-lisp* buffer. In contrast, if I do not run this through slime, but just run it from a terminal the lisp implementaiton is not killed. I assume that the serial bluetooth connection is closed from the other side and that that somehow closes also the slime connection. But I don't know why, if this is normal, and how to change this behaviour. All hints are appreciated. Wim Oudshoorn.
* Willem Rein Oudshoorn [2009-06-01 15:52+0200] writes:
I need some hints to start figuring out why I regularly get a "Process inferior-lisp hangup" in my *inferior-lisp* buffer, but I do not have clue where to start.
Situation:
* OS: Mac OS X * Lisp version: sbcl 64bit 1.0.28 and ccl 1.3-r12156M (64bit) * Slime version: CVS version as of today.
"Reproduction Scenario"
1 Start slime with one of the two lisp implementaitons mentioned above 2 Open "/dev/tty.NXT-DevB-1", which is a serial blue tooth connection to a Lego NXT brick. 3 Turn of the Lego NXT brick (the other side of the serial connection)
Fancy toys.
After this, I get the "Process inferior-lisp hangup" in the *inferior-lisp* buffer.
In contrast, if I do not run this through slime, but just run it from a terminal the lisp implementaiton is not killed.
I assume that the serial bluetooth connection is closed from the other side and that that somehow closes also the slime connection. But I don't know why, if this is normal, and how to change this behaviour.
All hints are appreciated.
To me it looks like the subprocess receives a SIGHUP when the serial connection goes down. At least http://en.wikipedia.org/wiki/SIGHUP mentions that as the historical usage of SIGHUP. Perhaps it helps if you install a signal handler for SIGHUP to ignore it. It might also help to bind process-connection-type in slime-start-lisp to 'pty instead of nil. Helmut.
2009/6/1 Helmut Eller <heller@common-lisp.net>:
To me it looks like the subprocess receives a SIGHUP when the serial connection goes down. At least http://en.wikipedia.org/wiki/SIGHUP mentions that as the historical usage of SIGHUP.
Perhaps it helps if you install a signal handler for SIGHUP to ignore it. It might also help to bind process-connection-type in slime-start-lisp to 'pty instead of nil.
If SIGHUP is the cause, then (sb-unix::ignore-interrupt sb-unix::sighup) is the immediate bandaid to making SBCL ignore it. (Caveat: SB-UNIX is an internal implementation package, and the APIs there may change or go away without warning -- if this solves your problem, let us know so that when someone has enough spare cycles we can figure out a supported API for your needs.) Cheers, -- Nikodemus
About problem with slime connection unexpected closed when a bluetooth serial connection is broken. Nikodemus Siivola <nikodemus@random-state.net> writes:
2009/6/1 Helmut Eller <heller@common-lisp.net>:
Perhaps it helps if you install a signal handler for SIGHUP to ignore it. It might also help to bind process-connection-type in slime-start-lisp to 'pty instead of nil.
If SIGHUP is the cause, then
(sb-unix::ignore-interrupt sb-unix::sighup)
is the immediate bandaid to making SBCL ignore it. (Caveat: SB-UNIX is an internal implementation package, and the APIs there may change or go away without warning -- if this solves your problem, let us know so that when someone has enough spare cycles we can figure out a supported API for your needs.)
The (sb-unix::ignore-interrupt sb-unix::sighup) works, so the SIGHUP theory seems very plausible. I haven't tried to bind process-connection-type to 'pty yet. I will try that tomorrow. Thanks a lot for figuring this out, it makes it much more pleasant to work on this. (The NXT device shut itself off after a period of inactivity, and it was very annoying that the lisp image was killed as well.) Kind regards, Wim Oudshoorn.
Helmut Eller <heller@common-lisp.net> writes:
1 Start slime with one of the two lisp implementaitons mentioned above 2 Open "/dev/tty.NXT-DevB-1", which is a serial blue tooth connection to a Lego NXT brick. 3 Turn of the Lego NXT brick (the other side of the serial connection)
Fancy toys.
Yes, a great present from my girlfriend.
In contrast, if I do not run this through slime, but just run it from a terminal the lisp implementaiton is not killed.
To me it looks like the subprocess receives a SIGHUP when the serial connection goes down. At least http://en.wikipedia.org/wiki/SIGHUP mentions that as the historical usage of SIGHUP.
This is indeed the problem, see below for what happens.
Perhaps it helps if you install a signal handler for SIGHUP to ignore it.
This works.
It might also help to bind process-connection-type in slime-start-lisp to 'pty instead of nil.
This does not work. After some playing around, I have some better idea of what happens. * SIGHUP is send if darwin detects that the controlling terminal of a process is disconnected. * SIGHUP kills the lisp process * If lisp is started from the command line, the lisp process has a controlling terminal, presumably setup by the shell. * If lisp is started by slime, the lisp process does not have a controlling terminal. * If the lisp image opens the /dev/tty.NXT-DevB-1 device and the lisp process does not have a controlling terminal, the /dev/tty.NXT-DevB-1 becomes a controlling terminal. The upshot is, that: 1 - If lisp is started through slime, the NXT device will become a controlling terminal and therefore, breaking the connection will send a SIGHUP to the lisp process. Duefully killing the lisp process. 2- If lisp is started from the command line, the NXT device does NOT become a controlling terminal and therefore lisp is not killed by breaking the bluetooth connection. So it seems that everything works as it should. Although, I rather not spend my time debugging these kind of issues :-(. I assume now that I have to use implementation dependend hacks to configure the /dev/tty.NXT-DevB-1 device to configure the terminal NOT to send SIGHUP when connection goes away, or make sure the terminal will not be a controlling terminal. Bleh. Anyway, thanks for the help, it has been educational. Wim Oudshoorn.
2009/6/3 Willem Rein Oudshoorn <woudshoo@xs4all.nl>:
I assume now that I have to use implementation dependend hacks to configure the /dev/tty.NXT-DevB-1 device to configure the terminal NOT to send SIGHUP when connection goes away, or make sure the terminal will not be a controlling terminal. Bleh.
Running the lisp under "nohup" is probably the easiest portable way. Cheers, -- Nikodemus
participants (3)
-
Helmut Eller -
Nikodemus Siivola -
Willem Rein Oudshoorn