Join GitHub today
lisps instantiated by M-x slime get killed when reading from unexpectedly unplugged USB serial devices #333
So in order to reproduce this bug on my linux 64 bit laptop or desktop arch linux setup (emacs 24.5.1 on the desktop):
On my machine something kills the inferior-lisp. I'm guessing slime catches sighup and does the deed.
If I manually fire up a lisp, run swank, then M-x slime-connect it drops me into the slime debugger as expected with "Unexpected end of file" - so at least I have a workaround for now!
lisps instantiated by M-x slime get killed when reading from unplugged USB serial devices
lisps instantiated by M-x slime get killed when reading from unexpectedly unplugged USB serial devices
changed the title from
Aug 23, 2016
Can't reproduce exactly the same behaviour using "kill -s HUP".
The symptoms are the same as yanking a usb cable for the lisp started with M-x slime - i.e lisp dies without dropping into debugger with the message "Process inferior-lisp hangup".
However with a lisp started manually "kill -s HUP" still kills the process, rather than dropping into the debugger. Dunno if that's expected or not!?
Discovered another workaround, using the trivial-signal package:
(trivial-signal:signal-handler-bind ((#.trivial-signal:+sighup+ (lambda (x) (print 'zoinks)))) (with-open-file (foo "/dev/ttyUSB0" :direction :input :if-exists :overwrite :element-type '(unsigned-byte 8)) (loop (print (read-byte foo)))))
Either sending sighup via kill, or yanking the usb cable triggers the signal-handler for sighup, but game-over now prevented, even for a lisp started with M-x slime. Yanking the usb cable raises an additional condition "Unexpected end of file", as expected...
I see exactly the same behaviour with sbcl instead of CCL for 6 test cases. Summarised version of the results: