Hi all,
I'm new to SLIME, although a co-worker has been prodding me to look at it for a year. I'm also new to SBCL, although I used CMUCL a fair amount several years ago.
I apologize if the following is a FAQ -- I scoured the manual and searched through the gmane archives of this list, but I could've missed something.
When I write a core image out from SBCL which I'm talking to via SLIME, then try to load it from the command line without SLIME, I get a long stream of warning messages. This happens immediately on startup. I've deleted my .sbclrc file so user init is not to blame. (Also, when I start up SBCL from the shell, this doesn't happen.)
The lisp is not dead, just injured; I can get out of the break loop. However, any time I get back into a break loop, I'm in trouble again.
My co-worker suggested setting *debugger-hook* to nil, so I tried that, to no avail. I still get the errors (example below), and once I get back to a usable prompt in the lisp, I see that it's set to SWANK:SWANK-DEBUGGER-HOOK again.
I've copied the first chunk of what I see on startup to the end of this message. This is MacOSX, SLIME from CVS a day or two ago, SBCL 1.0.23.
Any advice?
Thanks,
Michael
--- * Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE # {128E6F6D}>)[:EXTERNAL] 1: (BACKTRACE 536870911 #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {128E6DE9}>) [...] 17: (FORMAT #<SB-SYS:FD-STREAM for "a socket" {10026331}> "~6,'0x")[:EXTERNAL] 18: (SWANK::ENCODE-MESSAGE (:DEBUG 0 11 ("Couldn't write to #<SB-SYS:FD-STREAM for \"a socket\" {10026331}>: Bad file descriptor" " [Condition of type SB-INT:SIMPLE-STREAM-ERROR]" NIL) (("ABORT" "Return to sldb level 10.") [... and a lot more ...]) 19: (SWANK::SLDB-LOOP 11) 20: (SWANK::SLDB-LOOP 11)[:EXTERNAL] 21: (SWANK::CALL-WITH-BINDINGS ((*PRINT-PRETTY* . T) (*PRINT-LEVEL* . 4) (*PRINT-LENGTH* . 10) (*PRINT-CIRCLE* . T) (*PRINT-READABLY*) (*PRINT-PPRINT-DISPATCH* . #<SB-PRETTY:PPRINT-DISPATCH-TABLE {10224B19}>) (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*) (*PRINT-ARRAY* . T) (*PRINT-LINES*) (*PRINT-ESCAPE* . T) (*PRINT-RIGHT-MARGIN* . 65) (SWANK::*SLDB-BITVECTOR-LENGTH* . 25) (SWANK::*SLDB-STRING-LENGTH* . 50)) #<FUNCTION (LAMBDA NIL) {10245C55}>) 22: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA NIL) {10245C05}>) 23: (SWANK::DEBUG-IN-EMACS #<SB-INT:SIMPLE-STREAM-ERROR {12771809}>) 24: (SWANK:INVOKE-SLIME-DEBUGGER #<SB-INT:SIMPLE-STREAM-ERROR {12771809}>) 25: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {12771A2D}>) 26: (SWANK:SWANK-DEBUGGER-HOOK #<SB-INT:SIMPLE-STREAM-ERROR {12771809}> #<unavailable argument>) 27: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-STREAM-ERROR {12771809}>) 28: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-STREAM-ERROR {12771809}>)[:EXTERNAL] [... and on for hundreds of lines ...]
Michael Hannemann mrh3@pobox.com writes:
When I write a core image out from SBCL which I'm talking to via SLIME, then try to load it from the command line without SLIME, I get a long stream of warning messages. This happens immediately on startup. I've deleted my .sbclrc file so user init is not to blame. (Also, when I start up SBCL from the shell, this doesn't happen.)
It is not a good idea trying to invoke SB-EXT:SAVE-LISP-AND-DIE while Slime is connected to a running SWANK server.
Forking first, and then invoking it, is a somewhat better idea, although I'm not certain (and not knowledgeable enough) about how good it really is. There's a SWANK-BACKEND:SAVE-IMAGE function which, on SBCL, goes the fork route but does not seem to work at all right now.
Any advice?
Do not do this. :-)
-T.
Tobias C. Rittweiler wrote:
Michael Hannemann mrh3@pobox.com writes:
When I write a core image out from SBCL which I'm talking to via SLIME, then try to load it from the command line without SLIME, I get a long stream of warning messages. This happens immediately on startup. I've deleted my .sbclrc file so user init is not to blame. (Also, when I start up SBCL from the shell, this doesn't happen.)
It is not a good idea trying to invoke SB-EXT:SAVE-LISP-AND-DIE while Slime is connected to a running SWANK server.
Forking first, and then invoking it, is a somewhat better idea, although I'm not certain (and not knowledgeable enough) about how good it really is. There's a SWANK-BACKEND:SAVE-IMAGE function which, on SBCL, goes the fork route but does not seem to work at all right now.
I actually am forking first, but I didn't want to complicate the discussion unnecessarily. It took me a while to determine it was possible, since apart from an offhand reference in the SBCL manual, there was no documentation anywhere for SBCL forking itself, but I stumbled across the sb-posix contributed module and all was well.
So: How do I turn SWANK off in a child lisp which is about to save-and-die?
Also: Is there a good way of detecting that a SWANK server is running in the first place, other than seeing if (find-package :swank) returns something?
Thanks again,
Michael
* Michael Hannemann [2009-03-02 04:19+0100] writes:
Tobias C. Rittweiler wrote:
Michael Hannemann mrh3@pobox.com writes:
When I write a core image out from SBCL which I'm talking to via SLIME, then try to load it from the command line without SLIME, I get a long stream of warning messages. This happens immediately on startup. I've deleted my .sbclrc file so user init is not to blame. (Also, when I start up SBCL from the shell, this doesn't happen.)
It is not a good idea trying to invoke SB-EXT:SAVE-LISP-AND-DIE while Slime is connected to a running SWANK server.
Forking first, and then invoking it, is a somewhat better idea, although I'm not certain (and not knowledgeable enough) about how good it really is. There's a SWANK-BACKEND:SAVE-IMAGE function which, on SBCL, goes the fork route but does not seem to work at all right now.
I actually am forking first, but I didn't want to complicate the discussion unnecessarily. It took me a while to determine it was possible, since apart from an offhand reference in the SBCL manual, there was no documentation anywhere for SBCL forking itself, but I stumbled across the sb-posix contributed module and all was well.
So: How do I turn SWANK off in a child lisp which is about to save-and-die?
Forking is tricky due the inherited file-descriptors and it's also not well specified whether threads are cloned or not.
In theory you can call (swank::close-connection (swank::default-connection) nil nil) to clean things up, but the whole shutdown mechanism doesn't work all that well with threads.
[During shutdown we just want to kill our threads which can generate certain errors. Handling those errors outside of the thread in which the error occurred is rather difficult. Or at least I've never seen a way to do that cleanly. This becomes even more complicated after fork.]
If you use global i/o redirection then you should also call swank::revert-global-io-redirection somewhere.
Also: Is there a good way of detecting that a SWANK server is running in the first place, other than seeing if (find-package :swank) returns something?
Testing swank::*connections* and swank::*listener-sockets* should work. Both should be nil when everything is closed.
Helmut.
On Lunes 02 Marzo 2009, Helmut Eller wrote:
- Michael Hannemann [2009-03-02 04:19+0100] writes:
Tobias C. Rittweiler wrote:
Michael Hannemann mrh3@pobox.com writes:
When I write a core image out from SBCL which I'm talking to via SLIME, then try to load it from the command line without SLIME, I get a long stream of warning messages. This happens immediately on startup. I've deleted my .sbclrc file so user init is not to blame. (Also, when I start up SBCL from the shell, this doesn't happen.)
It is not a good idea trying to invoke SB-EXT:SAVE-LISP-AND-DIE while Slime is connected to a running SWANK server.
Forking first, and then invoking it, is a somewhat better idea, although I'm not certain (and not knowledgeable enough) about how good it really is. There's a SWANK-BACKEND:SAVE-IMAGE function which, on SBCL, goes the fork route but does not seem to work at all right now.
I actually am forking first, but I didn't want to complicate the discussion unnecessarily. It took me a while to determine it was possible, since apart from an offhand reference in the SBCL manual, there was no documentation anywhere for SBCL forking itself, but I stumbled across the sb-posix contributed module and all was well.
So: How do I turn SWANK off in a child lisp which is about to save-and-die?
Forking is tricky due the inherited file-descriptors and it's also not well specified whether threads are cloned or not.
SBCL's thread implementation is based on pthreads, ergo fork() does not clone threads. From the fork() manpage on my linux x86 box:
* The child process is created with a single thread — the one that called fork(). The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects; the use of pthread_atfork(3) may be helpful for dealing with problems that this can cause.
In theory you can call (swank::close-connection (swank::default-connection) nil nil) to clean things up, but the whole shutdown mechanism doesn't work all that well with threads.
[During shutdown we just want to kill our threads which can generate certain errors. Handling those errors outside of the thread in which the error occurred is rather difficult. Or at least I've never seen a way to do that cleanly. This becomes even more complicated after fork.]
If you use global i/o redirection then you should also call swank::revert-global-io-redirection somewhere.
Also: Is there a good way of detecting that a SWANK server is running in the first place, other than seeing if (find-package :swank) returns something?
Testing swank::*connections* and swank::*listener-sockets* should work. Both should be nil when everything is closed.
Helmut.
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
-
Gábor Melis -
Helmut Eller -
Michael Hannemann -
Tobias C. Rittweiler