Esteemed hunchentoot developers,
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
thanks,
Cyrus
Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client: 192.168.0.101:50690)" RUNNING {100427B6A1}> :STATE 1). [Condition of type SIMPLE-ERROR]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 192.168.0.101:50690)" RUNNING {100427B6A1}>)
Backtrace: 0: (SB-THREAD:GET-MUTEX #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) 1: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 2: (HUNCHENTOOT::LOG-MESSAGE-TO-FILE :ERROR "Error while processing connection: ~A")[:EXTERNAL] 3: ((FLET #:LAMBDA103) #<SIMPLE-ERROR "Recursive lock attempt ~S." {1003715361}>) 4: (SIGNAL #<SIMPLE-ERROR "Recursive lock attempt ~S." {1003715361}>)[:EXTERNAL] 5: (ERROR "Recursive lock attempt ~S.")[:EXTERNAL] 6: (SB-THREAD:GET-MUTEX #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) 7: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 8: (SB-THREAD::CALL-WITH-MUTEX ..) 9: (HUNCHENTOOT::LOG-MESSAGE-TO-FILE :ERROR "~A~:[~*~;~%~:*~A~]")[:EXTERNAL] 10: ((FLET #:LAMBDA250) #<SB-INT:SIMPLE-FILE-ERROR "~@<~?: ~2I~_~A~:>" {10036AD531}>) 11: (SIGNAL #<SB-INT:SIMPLE-FILE-ERROR "~@<~?: ~2I~_~A~:>" {10036AD531}>)[:EXTERNAL] 12: (ERROR SB-INT:SIMPLE-FILE-ERROR)[:EXTERNAL] 13: (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"/usr/home/sly/projects/priv.cyrusharmon.org/hunchentoot-launcher/log/hunchentoot-message.log" 13) 14: ((LABELS SB-IMPL::VANILLA-OPEN-ERROR)) 15: (OPEN #P"/usr/home/sly/projects/priv.cyrusharmon.org/hunchentoot-launcher/log/hunchentoot-message.log")[:EXTERNAL] 16: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 17: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 18: (SB-THREAD::CALL-WITH-MUTEX ..) 19: (HUNCHENTOOT::LOG-MESSAGE-TO-FILE :INFO "Default handler called for script ~A")[:EXTERNAL] 20: (HUNCHENTOOT::DEFAULT-HANDLER) 21: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-REQUEST (HUNCHENTOOT:ACCEPTOR HUNCHENTOOT:REQUEST)) ..) 22: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:REQUEST {1003587951}>) 23: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) ..) 24: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) ..) 25: ((LAMBDA ())) 26: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK369]374))
On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
I agree. Can you supply a patch that corrects the problem? Using a recursive lock would probably the easiest solution.
Thanks, Hans
I'm not sure that's the best solution. Running into trouble while trying to log an error message is always a pain in the neck, but it's usually not best to just go ahead anyway. I try to write fallbacks. (Hans, I'm sure you know about this idea; I'm just saying it might be good in this case.)
Here's a simple example of what I mean.
(defun safe-format (stream control-string &rest format-arguments) "This is like FORMAT, except that if a condition is signaled during the call to FORMAT, it falls back by printing the FORMAT control string, followed by as many of the arguments as possible. This function never signals any conditions. This means that it can hide errors, so it should not be used widely. It is intended to be used in code that reports errors and stack traces, and in logging." (handler-case (apply #'format stream control-string format-arguments) (serious-condition () (ignore-errors (flet ((print-fallback (stream) (princ "Error during format: " stream) (princ control-string stream) (dolist (arg format-arguments) (princ " " stream) (handler-case (princ arg stream) (serious-condition () (ignore-errors (princ "[error printing argument of type " stream) (ignore-errors (princ (type-of arg) stream)) (princ "]" stream))))))) (if (null stream) (with-output-to-string (strm) (print-fallback strm)) (print-fallback stream)))))))
-- Dan
Hans Hübner wrote:
On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
I agree. Can you supply a patch that corrects the problem? Using a recursive lock would probably the easiest solution.
Thanks, Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I have no idea if this is the right thing to do for lispworks or not, but this seems to work on SBCL.
Thanks,
Cyrus
On Jun 15, 2010, at 9:39 PM, Hans Hübner wrote:
On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
I agree. Can you supply a patch that corrects the problem? Using a recursive lock would probably the easiest solution.
Thanks, Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Cyrus,
Thanks for the patch, but I'm order for this one to be accepted it should work for LispWorks as well. I'd look into it myself, but I currently have problems with my arm/shoulder which prevent me from sitting at my desk for longer periods.
Cheers, Edi.
On Wed, Jun 23, 2010 at 8:33 AM, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
I have no idea if this is the right thing to do for lispworks or not, but this seems to work on SBCL.
Thanks,
Cyrus
On Jun 15, 2010, at 9:39 PM, Hans Hübner wrote:
On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
I agree. Can you supply a patch that corrects the problem? Using a recursive lock would probably the easiest solution.
Thanks, 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
Hi,
Edi and I discussed this matter and we agreed that my suggestion that using a recursive lock would solve the problem does not really hold. With the same situation (error signaled while holding the lock and logging, resulting in another log invocation), the recursive lock would result in an infinite recursion and finally stack exhaustion. This would not be an improvement.
I think Dan's contribution was good: It should be attempted to do fine-grained error handling for the arguments while logging, and errors while logging should certainly not make the code re-enter the logging code.
Cyrus, did you actually verify that your patch solves the problem? We might be missing something.
Thanks, Hans
On Wed, Jun 23, 2010 at 08:40, Edi Weitz edi@agharta.de wrote:
Cyrus,
Thanks for the patch, but I'm order for this one to be accepted it should work for LispWorks as well. I'd look into it myself, but I currently have problems with my arm/shoulder which prevent me from sitting at my desk for longer periods.
Cheers, Edi.
On Wed, Jun 23, 2010 at 8:33 AM, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
I have no idea if this is the right thing to do for lispworks or not, but this seems to work on SBCL.
Thanks,
Cyrus
On Jun 15, 2010, at 9:39 PM, Hans Hübner wrote:
On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
I agree. Can you supply a patch that corrects the problem? Using a recursive lock would probably the easiest solution.
Thanks, 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