[hunchentoot-devel] hunchentoot-1.2.2 throw a Recursive lock attempt error in sbcl 1.0.55
Hi all, I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: ============================================================================ (make-instance 'acceptor :address "127.0.0.1" :port port :access-log-destination (strcat *log-path* "access.log") :message-log-destination (strcat *log-path* "message.log")) ============================================================================ A few hours later,hunchentoot will throw an error message like this: ============================================================================ debugger invoked on a SIMPLE-ERROR in thread #<THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}>: Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}> :STATE 1). ============================================================================ And the site will not hand request any more. stop server seems dead too. I have to roll back to 1.1.1 at this time. With Best Regards. ___________________________________ Jingtao Xu www.jingtao.net
How about using easy-acceptor instead of acceptor ? 在 Wed, 29 Feb 2012 09:55:36 +0800，Xu Jingtao <jingtaozf@gmail.com> 写道:
Hi all,
I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: ============================================================================ (make-instance 'acceptor :address "127.0.0.1" :port port :access-log-destination (strcat *log-path* "access.log") :message-log-destination (strcat *log-path* "message.log")) ============================================================================
A few hours later,hunchentoot will throw an error message like this: ============================================================================ debugger invoked on a SIMPLE-ERROR in thread #<THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}>: Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}> :STATE 1). ============================================================================ And the site will not hand request any more.
stop server seems dead too.
I have to roll back to 1.1.1 at this time.
With Best Regards. ___________________________________ Jingtao Xu www.jingtao.net
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Sorry,I use easy-acceptor indeed. the code below should be easy-acceptor.
How about using easy-acceptor instead of acceptor ?
在 Wed, 29 Feb 2012 09:55:36 +0800，Xu Jingtao <jingtaozf@gmail.com> 写道:
Hi all,
I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: ============================================================================ (make-instance 'acceptor :address "127.0.0.1" :port port :access-log-destination (strcat *log-path* "access.log") :message-log-destination (strcat *log-path* "message.log")) ============================================================================
A few hours later,hunchentoot will throw an error message like this: ============================================================================ debugger invoked on a SIMPLE-ERROR in thread #<THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}>: Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}> :STATE 1). ============================================================================ And the site will not hand request any more.
stop server seems dead too.
I have to roll back to 1.1.1 at this time.
With Best Regards. ___________________________________ Jingtao Xu www.jingtao.net
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/ _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Feb 28, 2012 at 8:55 PM, Xu Jingtao <jingtaozf@gmail.com> wrote:
I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: [...] A few hours later,hunchentoot will throw an error message like this:
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}>: Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}> :STATE 1).
I have not been able to reproduce this problem. Can you provide a way to reproduce it? Thanks, -Hans
Hi Hans, My server OS is debian 6.0(i686). Some hunchentoot setup codes like this: ======================================================================== (defclass my-site-acceptor (easy-acceptor) () (:documentation "This is the acceptor of the my-site framework.")) (defmethod acceptor-status-message ((acceptor my-site-acceptor) http-status-code &key &allow-other-keys) (when (/= http-status-code +http-service-error-handling+) (call-next-method))) (defmethod acceptor-remove-session ((acceptor my-site-acceptor) (session t)) (declare (ignore acceptor)) (loop for path in (session-value :|temp files|) do (ignore-errors (delete-file path)))) (defun start-site (&key (port 3001)) (cond (*site-acceptor* (warn "site has been started.") *site-acceptor*) (t (setf *site-acceptor* (make-instance 'my-site-acceptor :address "127.0.0.1" :port port :access-log-destination (strcat *log-path* "access.log") :message-log-destination (strcat *log-path* "message.log"))) (reset-session-secret) (start *site-acceptor*)))) ======================================================================== I have defined many pages with 'define-easy-handler',reproducing it is difficult because the server runs fine when started,they hung after random hours(sometimes many days) later, when people visit my site.
(SB-THREAD:MUTEX
:NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:43115" RUNNING {C4F7F19}> :STATE 1).
I have not been able to reproduce this problem. Can you provide a way to reproduce it?
Thanks, -Hans
___________________________________ Jingtao Xu A Lisp Programmer www.jingtao.net
From looking at the code, it seems that the problem could be triggered by an error that is triggered from within the logging code, i.e. when another error is triggered while writing to the error log. One possible cause could be disk shortage.
I will open up a tracker issue for the problem. -Hans
Hi Hans, My disk is enough,and this error happened in hunchentoot 1.1.1 too, but it don't crash my web server.
From looking at the code, it seems that the problem could be triggered by an error that is triggered from within the logging code, i.e. when another error is triggered while writing to the error log. One possible cause could be disk shortage.
I will open up a tracker issue for the problem.
-Hans
Jingtao Xu A Lisp Programmer www.jingtao.net
Can you test whether the patch https://github.com/edicl/hunchentoot/commit/f4a3bbd5a915f83c42ff2351978f2e34... fixes your problem? If so, you should see a message on the console when logging an error failed. Please share that message. My suspicion is that the problem is related to character encoding problems (i.e. Hunchentoot tries to write characters that cannot be encoded in the external format of the error log stream), but at this point, this is just a guess. The error message will help. Thanks, Hans On Wed, Feb 29, 2012 at 8:19 PM, Xu Jingtao <jingtaozf@gmail.com> wrote:
Hi Hans,
My disk is enough,and this error happened in hunchentoot 1.1.1 too, but it don't crash my web server.
From looking at the code, it seems that the problem could be triggered by an error that is triggered from within the logging code, i.e. when another error is triggered while writing to the error log. One possible cause could be disk shortage.
I will open up a tracker issue for the problem.
-Hans
Jingtao Xu A Lisp Programmer www.jingtao.net
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Hans, I have update your patch to my web server(its hunchentoot version is 1.1.1). If I found some error output,I'll send them to this mail list. My site use a flexi-stream with cp936 patched (https://github.com/jingtaozf/flexi-streams). And the site use utf-8 as default encoding but some browser send us cp936 characters sometimes. With Best Regards. jingtao.
https://github.com/edicl/hunchentoot/commit/f4a3bbd5a915f83c42ff2351978f2e34... fixes your problem? If so, you should see a message on the console when logging an error failed. Please share that message. My suspicion is that the problem is related to character encoding problems (i.e. Hunchentoot tries to write characters that cannot be encoded in the external format of the error log stream), but at this point, this is just a guess. The error message will help.
Thanks, Hans
Hi Hans, This is some output of my sbcl 1.0.55 on debian 6.0(i686): =========================================== error error in FORMAT: unknown format directive (character: Return) This sequence can't be decoded ~ using ~A as it is too short. ~A octet~:P missing at then end. ^ while processing indirect format string: [~A~@[ [~A]~]] ~?~% ^ while writing to error log, error not logged error error in FORMAT: unknown format directive (character: Return) This sequence can't be decoded ~ using ~A as it is too short. ~A octet~:P missing at then end. ^ while processing indirect format string: [~A~@[ [~A]~]] ~?~% ^ while writing to error log, error not logged =========================================== With best regards,jingtao. 2012/3/1 Xu Jingtao <jingtaozf@gmail.com>
Hi Hans,
I have update your patch to my web server(its hunchentoot version is 1.1.1). If I found some error output,I'll send them to this mail list.
My site use a flexi-stream with cp936 patched ( https://github.com/jingtaozf/flexi-streams). And the site use utf-8 as default encoding but some browser send us cp936 characters sometimes.
With Best Regards. jingtao.
https://github.com/edicl/hunchentoot/commit/f4a3bbd5a915f83c42ff2351978f2e34...
fixes your problem? If so, you should see a message on the console when logging an error failed. Please share that message. My suspicion is that the problem is related to character encoding problems (i.e. Hunchentoot tries to write characters that cannot be encoded in the external format of the error log stream), but at this point, this is just a guess. The error message will help.
Thanks, Hans
On Sat, Mar 3, 2012 at 8:16 AM, Jingtao Xu <jingtaozf@gmail.com> wrote:
This is some output of my sbcl 1.0.55 on debian 6.0(i686): =========================================== error error in FORMAT: unknown format directive (character: Return) This sequence can't be decoded ~ using ~A as it is too short. ~A octet~:P missing at then end. ^ while processing indirect format string: [~A~@[ [~A]~]] ~?~% ^ while writing to error log, error not logged error error in FORMAT: unknown format directive (character: Return)
This seems to be a nasty one. How did you get your copy of flexi-streams? It seems that it has been extracted with DOS line endings, and SBCL does not support that. While it will treat the #\Return characters as white space in source code and skip it, it will read it into string literals. In this case, the #\Return ended up in a format string in flexi-streams' length.lisp file and caused an error, as ~#\Return is not a valid format control sequence. One could debate whether SBCL is buggy here or not, but in any case, you can solve the problem by making sure that your Lisp source files have only Linefeeds as line endings under Linux. Thank you for reporting the bug in Hunchentoot! The fix will be part of the next release. -Hans
That's my pleasure. I'll check my codes as you suggest. Thanks very much!
This seems to be a nasty one. How did you get your copy of flexi-streams? It seems that it has been extracted with DOS line endings, and SBCL does not support that. While it will treat the #\Return characters as white space in source code and skip it, it will read it into string literals. In this case, the #\Return ended up in a format string in flexi-streams' length.lisp file and caused an error, as ~#\Return is not a valid format control sequence.
One could debate whether SBCL is buggy here or not, but in any case, you can solve the problem by making sure that your Lisp source files have only
___________________________________
I use flexi-streams from here: https://github.com/jingtaozf/flexi-streams
be a nasty one. How did you get your copy of flexi-streams?
On Sat, Mar 3, 2012 at 8:50 AM, Xu Jingtao <jingtaozf@gmail.com> wrote:
I use flexi-streams from here: https://github.com/jingtaozf/flexi-streams
I would like to eventually merge the changes into the official flexi-streams version, but as they are relatively large, I'm hesitant to do it right away. I've opened an issue to remind me to do it. Thanks, Hans
participants (4)
-
Hans Hübner -
Jingtao Xu -
Xu Jingtao
-
z_axis