[cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution?

[Anton Vodonosov]

Hello.

Short status of this problem.

There was a discussion on the openmcl-devel: http://thread.gmane.org/gmane.lisp.openmcl.devel/7124.
In short, I hoped the CCL developers know a fast way to debug crashes. Gary Byers says he can't suggest
a way to find out the reason of the crash. He also says it _might_ be a CCL bug, but he will start working
on it only if the problem will be isolated enough to prove it's a CCL bug and not a bug in CL+SSL, CFFI or 
some other component.

Today I again worked a bit with the test case sent us by John Klein (which reproduces the crash without
hunchentoot, by creating a toy server).

BTW, for me both functions from this example - test-https-server/bad and test-https-server/good -
result in crash (and I even don't use ApacheBench, just use a web browser). Therefore the assumption
that the key to the crash is calling cl+ssl:make-ssl-server-stream in a different thread is not true.

Can anyone confirm this?

Anyway. I found an interesting thing. I modified slightly the example (attached), so that all the server 
accept/handle-request loop runs in a single thread (without creating a new thread for every request).

In this case the server doesn't crash when I access it from a web browser.

But. When after this in the REPL I run (QUIT)  the crash happens. It also crashes
if instead of (QUIT) I run (CCL:SAVE-APPLICATION "my.image"),

So the test case:

1. Load the example-threaded.lisp from the attach.
2. Open https://localhost:8181/yo in a web browser. CCL should not crash.
3. Type (QUIT) or (CCL:SAVE-APPLICATION "my.image") in the CCL REPL. It crashes.

Why I think it's important. It allows to narrow the search area. Looks like the crash happens not when 
the callback is called, but later. We as if put the system into some state, when calling QUIT crashes it. 
I suppose calling QUIT does not cause OpenSSL library to perform any actions with the callback (it would 
be good to confirm this). If that's true, it's CCL who crashes, not the foreign code.

Another thing I started, is creating a small DLL, which will call a lisp callback, with the same 
prototype as the locking-callback in CL+SSL. I have the working example, but still
hadn't tested it with my CCL because my CCL is 64bit, and I don't have a 64 bit windows compiler
(need to download the win SDK).

Can anyone test it? (the example is attached, just load the cffi-only.lisp from the
same directory where mydll.dll is)

In general, I think finding the reason of the crash may require someone to spend several full
working days on this problem. I personally might be unable to devote this amount of time
to this problem in the nearest months. Others are probably in the similar situation, therefore
chances are hight this problem will remain unfixed some time.

Best regards,
- Anton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-threaded.lisp
Type: application/octet-stream
Size: 6028 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-plus-ssl-devel/attachments/20110508/6b65ca64/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cffi-only.zip
Type: application/zip
Size: 18059 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-plus-ssl-devel/attachments/20110508/6b65ca64/attachment.zip>