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

[Anton Vodonosov]

Hello.

08.04.2011, 21:41, "Daniel Brunner" <daniel at dbrunner.de>;;:

>   Therefore I suppose the CCL on Linux version is working/stable.

That's good.

>   On Windows (I tested the 32 Bit version) Hunchentoot crashes immediately.

Yes, I confirm, the crash happens at the first https request.

I did some more investigation. I have two suspects:

1. Microsoft visual C runtime libraries incompatibility.
2. CFFI/CCL bug

1. There is a FAQ item
http://www.openssl.org/support/faq.html#PROG2

It says that the OpenSSL library and the main program must be build using the same MS Visual C runtime
library. And CCL uses MSVCRT.DLL, while OpenSSL uses MSVCRT90.DLL. These are different versions.

But. There are reasons to think it's not the cause of the crash.

First of all. How the two runtime libraries can interfere, to produce a crash?

For example, if we malloc() memory using one library, and then pass the pointer to another parth,
where free() is called from the other runtime library, and another heap manager is user. This will produce a
crash.

Or, for example, OpenSSL BIO might be created from a FILE* pointer. It's the same: FILE* and
it's associated internal structures are created by C runtime of the caller, and are used by
the runtime of the OpenSSL.

Here are the MSDN explanations: http://msdn.microsoft.com/ru-ru/library/ms235460.aspx

But as I see, we are not doing anything like this. We create BIO just from a socket handle.
I also tried to user lisp BIO, so that no even socket handle is passed from CCL to OpenSSL.

The crash happens anyway.

2. Probably it's just a bug in CFFI/CCL?

I tried to comment out the locking-callback body, so that it's just an empty function.
The crash happens the same way. Also I run the CFFI test suite, there were
several failures (I reported the failure to the cffi-devel).

And if you don't install this callback - the crash doesn't happen.

An argument against the CFFI is that the locking-callback arguments are passed
to it correctly, without any corruption (I tied to log the callback invocations).

Also, the callback is called thousands of times before the crash happens.

So far, I can only conclude that more investigation is needed.
There are too many parts which might be the cause: FFI/CFFI, callbacks, multi-threading,
C runtime libraries, locks.

We need to isolate the cause somehow.

Best regards,
- Anton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dependency-explorer.png
Type: image/png
Size: 24164 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-plus-ssl-devel/attachments/20110410/e040b6ed/attachment.png>