-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Hans,
Hans Hübner wrote:
Peter, as I cannot reproduce the problem myself, can you please post a stack backtrace? Thanks!
The variable HUNCHENTOOT:*ACCEPTOR* is unbound. BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL). [Condition of type SIMPLE-CONDITION]
Restarts: 0: [CONTINUE] Return from BREAK. 1: [REASSIGN] Return from BREAK and assign a new value to *BREAK-ON-SIGNALS*. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot listener (*:8000)" RUNNING {C42AAE9}>)
Backtrace: 0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>) 1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL] 2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX.. 5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC) #<unavailable argument>) 6: ("foreign function: #x806480C") 7: ("foreign function: #x8052BCC") 8: ("foreign function: #x8056BD3") 9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread for new incoming connection: ~A")[:EXTERNAL] 10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..) 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>) 12: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 14: (SB-THREAD::CALL-WITH-MUTEX ..) 15: ((LAMBDA ())) 16: ("foreign function: #x806480C") 17: ("foreign function: #x8052C21") 18: ("foreign function: #x805BD9D") 19: ("foreign function: #xB7FB84C0")
I found that not attempting to log a message solved this remaining problem.
Thank you very much for your help!
/Peter
2009/7/6 Peter Stiernström peter.stiernstrom@blixtvik.se: Hans,
I should have realised I was editing the lispworks implementation myself had I only had a cup of coffee this morning :-P
Now when I tried your patch out I still get hangups but this is another kind of hangup:
debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot listener (*:8000)" RUNNING {AD467D1}>: The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
I am trying this out with the hunchentoot default page by the way.
/Peter
Hans Hübner wrote:
Peter,
sorry, I am not able to reproduce the problem myself, so I made the patch blindly and made a mistake, working on the Lispworks code rather than the portable code that affects you. Please look at the first hunk of this diff:
http://bknr.net/trac/changeset/4430?format=diff&new=4430
and let me know if that does it for you.
Sorry, Hans
On Mon, Jul 6, 2009 at 11:09, Peter Stiernströmpeter.stiernstrom@blixtvik.se wrote: Hi Hans,
Hans Hübner wrote:
> Hi Peter, > > 2009/7/6 Peter Stiernström peter.stiernstrom@blixtvik.se >> I had a quick peek at client-as-string and it does indeed not handle the >> sb-bsd-sockets:not-connected-error and if I put a handler-case around >> body of client-as-string returning nil when the exception appears I can >> not reproduce my problem anymore. >> >> This wouldn't provide a portable solution though :-P > This really is a bug that requires fixing in usocket. There are > multiple issues: > > - As shown in the backtrace, the problem is that the getpeername() > call fails for a socket that is not connected anymore. SBCL does the > right thing by signalling a condition. Other implementations (I > checked CCL) seem to behave differently, i.e. return NIL in such a > case. > > - Usocket does not unify the behavior, so the implementation specific > condition percolates to the caller, Hunchentoot in this case. > > - Hunchentoot is not prepared to handle conditions when creating a new > worker thread. The call to CLIENT-AS-STRING is made when creating the > name for the handler process of a new incoming connection, and that is > done in the context of the server thread. Therefore, the signalled > condition will stop the acceptor process. > > I spent some thoughts on how a "portable solution" would look like, > but given that the Lisp implementations vary greatly in behavior, > fixing usocket would be a pretty large task that I don't have the time > to do right now. Thus, I would propose this patch: > > http://bknr.net/trac/changeset/4428?format=diff&new=4428 > > It handles all conditions that are signaled during worker process > creation, under the theory that we want to prevent the acceptor > process from crashing under all circumstances. This is not a clean > solution in that it may paper over bugs, but given the limited number > of function invocations that are surrounded by a HANDLER-CASE, I'd say > that this is a proper intermediate fix. > > Please give it a try and let me know if it solves the problem for you.
I tried your suggested patch but I can't seem to be able to get it to catch the exception for me. Were you able to duplicate the error yourself to verify that the suggested patch does indeed work? Since I am using the 1.0.0 hunchentoot release I couldn't just apply your patch but added the handler-case by hand and thus ended up with this in taskmaster.lisp:
(defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) handle) (incf *worker-counter*) ;; check if we need to perform a global GC (when (and *cleanup-interval* (zerop (mod *worker-counter* *cleanup-interval*))) (when *cleanup-function* (funcall *cleanup-function*))) (handler-case (mp:process-run-function (format nil "Hunchentoot worker (client: ~{~A:~A~})" (multiple-value-list (get-peer-address-and-port handle))) nil #'process-connection (taskmaster-acceptor taskmaster) handle) (error (cond) (log-message *lisp-errors-log-level* "Error while creating worker thread for new incoming connection: ~A" cond))))
/Peter
> -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
- -- Med vänlig hälsning,
Peter Stiernström 0708-810932 Blixtvik AB