[hunchentoot-devel] ssl crashing in hunchentoot. ssl patch works in CCL, but not SBCL on mac - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

4 Apr 2011


      [cc'ed to hunchentoot list]
I  can confirm that ccl+hunchentoot on OS X 10.6 does not crash in 
ssl at a concurrency of 20 after 100,000 accesses (100% success in apache bench), 
whereas before it would crash after  a few hundred.
However, SBCL 1.0.47 is still freezing, but not coredumping.    It just times out
on the apachebench side, and in slime both the *inferior-lisp* and *slime-repl*
stop responding, and the CPU is pegged at 100%.
Using the toy server below,  ab also causes an eventual freeze in sbcl
but with CCL it mostly works, sometimes giving "SSL read failed - closing connection,"
which might be the fault of a premature close in the toy server (but I don't
see how to do it otherwise, besides waiting until the client side closes).   
So this isn't a hunchentoot problem, most likely.
Given that CCL+hunchentoot works perfectly maybe the problem is
inside SBCL, or maybe just the Mac version of SBCL if other platforms
now work.
-John
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; toy https server
;;
(eval-when (load eval compile)
  (require 'cl+ssl)
  (require 'bordeaux-threads)
  (require 'usocket))
(defparameter *keyfile* "./server.key")
(defparameter *certfile* "./server.crt")
;; the bad server associates an SSL with the client inside a 
;; worker thread, not inside the main thread
(defun test-https-server
    (&key (port 8080)
          (cert *certfile*)
          (key *keyfile*))
  (format t "~&SSL server listening on port ~d~%" port)
  (let ((server  (usocket:socket-listen "127.0.0.1" port 
    				:backlog 100)))
    (loop
      (let* ((socket (usocket:socket-accept server))
         (stream (usocket:socket-stream socket)))
    ;; launch response in a separate thread
    (bordeaux-threads:make-thread
       (lambda ()
         ;; MAKE SSL HERE
         (let ((client (cl+ssl:make-ssl-server-stream
    		    stream
    		    :external-format '(:iso-8859-1 :eol-style :lf)
    		    :certificate cert
    		    :key key)))
           (unwind-protect
    	    (progn
    	      (format client "HTTP/1.0 200 OK~%")
    	      (format client "Server: SSL-TEST/1.1~%")
    	      (format client "Content-Type: text/plain~%")
    	      (terpri client)
    	      (format client "HELLO WORLD")
    	      (finish-output client))
            ;; maybe apachebench is surprised by this close?
    	 (close client)))))))))
On Apr 3, 2011, at 3:26 AM, David Lichteblau wrote:
...
Hi,
Quoting David Lichteblau (david@lichteblau.com):
...
Quoting JTK (jetmonk@gmail.com):
[...]
...
...
I've appended a test case in which I think I may have found the source of
hunchentoot's problems with ssl and concurrency.
Does the attached patch help?
I have committed an updated version of the patch to CL+SSL CVS now.
This version works now because it avoids use of buggy code in the
bordeaux-threads backend for SBCL.
It passes ab testing on SBCL for me; I haven't rechecked other Lisps
yet.
...
It's done from Lisp, and should really be done directly in C, similar to
the th-lock.c sample code from OpenSSL.  But let's first check whether
it addresses the issue at all.
If anyone is interested in developing a C version, let's move to that
ultimately.  But I've decided to commit the Lisp version for now,
because I think that correctness should come before performance in this
case.
d.

cl-plus-ssl-devel mailing list
cl-plus-ssl-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel