[Openmcl-devel] CCL crash on windows (with multithreading and ffi callbacks)
Anton Vodonosov
avodonosov at yandex.ru
Sun May 1 14:30:27 PDT 2011
Hello.
Several people, including me, experience 100% reproducible CCL crash on Windows.
This involves multi-threading and FFI callbacks.
To reproduce this, you may assess hunchentoot via SSL (please use the recent CL+SSL from CVS).
The hunchentoot SSL connector uses OpenSSL via FFI. This includes providing a callback function
to OpenSSL. See call to the crypto-set-locking-callback in the ffi.lisp in the CL+SSL sources.
The crash happens, doesn't matter what code is inside of the callback. It may even be empty.
But if we don't pass the callback - the crash does not occur.
On Linux the crash doesn't happen. Also, on Windows, CLISP and Allegro CL doesn't crash.
For your convenience, below is the code to start hunchentoot with SSL. Ready to use certificate and key files
are also attached.
(pushnew "C:\\Users\\anton\\unpacked\\lisp-libs\\cl+ssl\\"
asdf:*central-registry*
:test #'equalp)
(ql:quickload :hunchentoot)
(defparameter *keyfile* "C:\\Users\\anton\\unpacked\\lisp-libs\\cl+ssl\\test-cert\\key.pem")
(defparameter *certfile* "C:\\Users\\anton\\unpacked\\lisp-libs\\cl+ssl\\test-cert\\certificate.pem")
(hunchentoot:define-easy-handler (say-yo :uri "/yo") (name)
(setf (hunchentoot:content-type*) "text/plain")
(format nil "Hey~@[ ~A~]!" name))
;; hunchentoot logging settings
(setf hunchentoot:*access-log-pathname* "C:/tmp/hunchentoot-access.log"
hunchentoot:*message-log-pathname* "C:/tmp/hunchentoot-message.log")
(defparameter *srv*
(hunchentoot:start (make-instance 'hunchentoot:ssl-acceptor
:port 8181
:ssl-certificate-file *certfile*
:ssl-privatekey-file *keyfile*
;; if you want to test a single-threaded case
;;:taskmaster (make-instance 'hunchentoot:single-threaded-taskmaster)
)))
(format t "Started. Server: ~A~%" *srv*)
This is the command line for the ApacheBench program on windows to query the
hunchentoot:
C:\Progra~2\Apache~1\Apache2.2\bin\abs -f SSL2 -n 1000 -c 14 -v 1 https://127.0.0.1:8181/yo?name=Dude
But the crash is quite easy reproduced from browser (I noticed, sometimes it happens not immediately
upon a request, but when you close the browser after received response).
My platform: Windows7 64bit, ccl-1.6-windowsx86 (also tried with ccl-trunk).
BTW, today I experienced another CCL crash (the same platform). I worked from slime, and run
a multi threaded test of my application. Probably it is a different problem, because it doesn't involve
any FFI, while the above test case doesn't crash if we don't pass an FFI callback.
I can't provide an isolated test case for the second problem. If you are interested to work on this,
the hunchentoot use case is easier to reproduce.
More links:
- If you need to know, why OpenSSL requires the callback:
http://www.openssl.org/docs/crypto/threads.html
Best regards,
- Anton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: certificate.pem
Type: application/octet-stream
Size: 855 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110502/252a76db/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: key.pem
Type: application/octet-stream
Size: 887 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110502/252a76db/attachment-0001.obj>
More information about the Openmcl-devel
mailing list