-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans Hübner wrote:
Oh well, *ACCEPTOR* was not inherited by the new process, so use this:
That seems to fix the last issue I had! Thanks a lot for your time Hans. Should one raise this issue to the attention of the usocket developers though?
/Peter
-Hans
On Mon, Jul 6, 2009 at 13:53, Peter Stiernströmpeter.stiernstrom@blixtvik.se wrote: Hans Hübner wrote:
Peter,
try this:
Hello Hans,
I still get an unbound-variable condition for hunchentoot:*acceptor* but the trace look a bit different:
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 worker (client: 127.0.0.1:46427)" RUNNING {AF2EA11}>)
Backtrace: 0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR* {AF30361}>) 1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AF30361}>)[:EXTERNAL] 2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX.. 5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5723CDC) #<unavailable argument>) 6: ("foreign function: #x806480C") 7: ("foreign function: #x8052BCC") 8: ("foreign function: #x8056BD3") 9: ((LAMBDA ())) 10: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 12: (SB-THREAD::CALL-WITH-MUTEX ..) 13: ((LAMBDA ())) 14: ("foreign function: #x806480C") 15: ("foreign function: #x8052C21") 16: ("foreign function: #x805BD9D") 17: ("foreign function: #xB7FB84C0")
I did set *break-on-signals* to 'unbound-variable and my modified function now looks like this:
(defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) (let ((*acceptor* (taskmaster-acceptor taskmaster))) (handler-case (bt:make-thread (lambda () (process-connection *acceptor* socket)) :name (format nil "Hunchentoot worker (client: ~A)" (client-as-string socket))) (error (e) (log-message *lisp-errors-log-level* "Error while creating worker thread for new incoming connection: ~A" e)))))
/Peter
-Hans
On Mon, Jul 6, 2009 at 13:21, Peter Stiernströmpeter.stiernstrom@blixtvik.se wrote: 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
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