Connection stream is not closed properly in request function about dexador HOT 5 CLOSED

Thank you for reporting.
Can you paste the error message and stack traces here?
For the moment, adding :keep-alive nil to the arguments might work as a workaround.

EDIT: Originally, I said :keep-alive t by mistake, but it obviously won't work since it's the default and the connection cache is enabled.

from dexador.

Unfortunately I don't get any stack traces or error messages, beyond SBCL terminating immediately with a return code 141. There is no chance to enter the debugger to poke around and see what's happening. It's like a core dump but no core file. Never seen SBCL do this, and so this may be tickling an underlying SBCL issue too.

The cycle that I found was the first post there were no issues. The second post would not complete (on Linux, not on macOS though) and the whole Lisp image would die. I isolated the point of failure to the finish-output call to to the following line in request:

(when chunkedp (setf (chunga:chunked-stream-output-chunking-p stream) nil)) (finish-output stream))))

At that point, SBCL dies, no questions asked. No debugger, no LDB, no error messages, and no local core file.

MacOS SBCL will not die, but will, after the post calls start to accumulate, will run out of file descriptors and the post will fail, but SBLC lives on.

Will check out :keep-alive nil, but I believe that is the default anyway so I wasn't expressly setting that key argument.

EDIT: forgot to add that the offending line above is in usocket.lisp, line 670 or so.

from dexador.

sbcl 2.0.9 (and not 2.0.8 nor 2.0.10) had a change that made it stop ignoring sigpipe (signal delivered when one writes to a socket that the other end has closed). Receiving sigpipe would cause sbcl to die quietly. If you are still using 2.0.9, consider upgrading, or there is a work around to tell sbcl to ignore the sigpipe.

That doesn't mean there isn't a bug in socket closing here, but just explains why it is hard to debug.

from dexador.

This should be fixed in the current (github) version of dexador. If you have time, could you verify?

from dexador.

Closing as out of date --- this should not happen if you use any SBCL except 2.0.9

from dexador.