I hope it is OK to send this to both the hunchentoot and cl+ssl lists. I think it is relevant to both.
I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency.
Code containing good and bad toy servers is attached at end of email.
Apologies in advance if this is way out in left field.
Here's my explanation - the comments in the code explain it in greater detail.
It appears that if you run a main listener thread and turn a client connection into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, and pass this ssl-socket to a child thread, then things work.
However, if you pass the raw socket to the child thread, and the child thread itself runs cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are concurrent connections.
It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream to child threads, as described in the comments to the code.
I'd be interested if people agree with the diagnosis. I'm not really clear on what the broader repercussions of moving the initialization are, so I haven't patched hunchentoot. (plus I might not have more time for a while).
John
Hi,
David L. has looked into this problem briefly and reports that the problem really is that cl+ssl is not thread safe as it currently stands. Fixing that is possible, but it is not entirely straightforward as cl+ssl needs to include a C file that implements functions to ensure thread safety.
Until that has been fixed, I would propose to make SSL and multi-threading in Hunchentoot incompatible.
Thoughts? -Hans
On Fri, Apr 1, 2011 at 8:43 AM, JTK jetmonk@gmail.com wrote:
I hope it is OK to send this to both the hunchentoot and cl+ssl lists. I think it is relevant to both.
I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency.
Code containing good and bad toy servers is attached at end of email.
Apologies in advance if this is way out in left field.
Here's my explanation - the comments in the code explain it in greater detail.
It appears that if you run a main listener thread and turn a client connection into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, and pass this ssl-socket to a child thread, then things work.
However, if you pass the raw socket to the child thread, and the child thread itself runs cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are concurrent connections.
It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream to child threads, as described in the comments to the code.
I'd be interested if people agree with the diagnosis. I'm not really clear on what the broader repercussions of moving the initialization are, so I haven't patched hunchentoot. (plus I might not have more time for a while).
John
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi,
I tested David's patch and my CCL (LinuxX8664) worked but the SBCL still crashes with
--8<-- CORRUPTION WARNING in SBCL pid 13380(tid 140737285650176): Memory fault at 0 (pc=0x7ffff4c7edfd, sp=0x7ffff3eae000) The integrity of this image is possibly compromised. Continuing with fingers crossed. --8<--
Kind regards, Daniel
Am 01.04.2011 13:59, schrieb Hans Hübner:
Hi,
David L. has looked into this problem briefly and reports that the problem really is that cl+ssl is not thread safe as it currently stands. Fixing that is possible, but it is not entirely straightforward as cl+ssl needs to include a C file that implements functions to ensure thread safety.
Until that has been fixed, I would propose to make SSL and multi-threading in Hunchentoot incompatible.
Thoughts? -Hans
On Fri, Apr 1, 2011 at 8:43 AM, JTK jetmonk@gmail.com wrote:
I hope it is OK to send this to both the hunchentoot and cl+ssl lists. I think it is relevant to both.
I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency.
Code containing good and bad toy servers is attached at end of email.
Apologies in advance if this is way out in left field.
Here's my explanation - the comments in the code explain it in greater detail.
It appears that if you run a main listener thread and turn a client connection into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, and pass this ssl-socket to a child thread, then things work.
However, if you pass the raw socket to the child thread, and the child thread itself runs cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are concurrent connections.
It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream to child threads, as described in the comments to the code.
I'd be interested if people agree with the diagnosis. I'm not really clear on what the broader repercussions of moving the initialization are, so I haven't patched hunchentoot. (plus I might not have more time for a while).
John
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Daniel Brunner -
Hans Hübner -
JTK