freenode/#sbcl - IRC Chatlog
Search
10:38:57
kuribas
that's two issues. The lisp service shouldn't be able to crash from a tcp problem, point.
10:40:51
jackdaniel
if I had to guess it goes like this: you connect to swank, your connection drops, and since there is dont-close nil and there is no interactive console it goes belly up due to no means to do anything. and after create-server poot (loop (sleep 1))
10:42:19
stassats
and you get "%PRIMITIVE HALT called; the party is over." when you're having nested errors, not "a tcp problem"
10:45:36
jackdaniel
stassats: dont-close causes serve-loop to return after the first connection. moreover if the communication-style is nil, then it is in the same thread as the caller. that's where my guess came from. (and yes, I am aware that a default communication style for sbcl is probably :spawn here)
10:57:42
kuribas
stassats: what happens is that I connect to the lisp server in emacs, there are network problems, the prompt hangs, and next the server crashes.
11:01:44
jackdaniel
I agree it is too little detail, but since you ask about "and then?" I'll go on with speculation: sbcl is started without i/o but no disable-debugger is passed, so sbcl tries to print something, that errors and we get into debugger form the debugger etc and it is a nested error leading to a primitive-halt (while if it were in a thread it would just crash said thread). either way even if I'm wrong that's
12:29:38
stassats
how flaky is flaky? i don't see what you can do to break the debugger, unless it's missing packets or something
12:42:59
stassats
it's more likely you're crashing it somewhere else and then misinterpreting the repl hanging as network problems
14:33:00
jackdaniel
when you type (print *features*) you have it printed and then its value is printed in the repl
14:37:00
jackdaniel
(null (print nil)) ; -> T, and it doesn't cover the fancy case ;) but more seriously, Lycurgus, print returns object it prints as its value