[hunchentoot-devel] ssl crashing in hunchentoot. ssl patch works in CCL, but not SBCL on mac

[JTK]

[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 at lichteblau.com):
>> Quoting JTK (jetmonk at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel