This is a repeat of an earlier problem one user had, as documented in this thread: http://common-lisp.net/pipermail/tbnl-devel/2006-December/000876.html
Basically, mx explanation in the other email was right except for the logging part. There should /probably/ be some cleanup that prevents errors like this one (that aren't really errors) to pop up the debugger.
Maybe an intrigued soul will contribute a patch. The bug is more of an annoyance than anything.
The original email before I noticed it was a repeat report:
I have been noticing this IO error since several months ago. When catch-signals is nil, hunchentoot occasionally throws me into the debugger. It signals at seemingly random points during a server's lifetime.
I have a backtrace, but I do not know the source of the error.
I am running a 64 bit version of SBCL, though I have noticed this on 32 bit SBCL, too.
I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> [Condition of type SB-SYS:IO-TIMEOUT]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-79" {10027721A1}>)
Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {10067D6969}>) 1: (SWANK::DEBUG-IN-EMACS #<SB-SYS:IO-TIMEOUT {1003007811}>) 2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003007C19}>) 3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C39}>) 4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C19}>) 5: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 6: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 8: (SIGNAL #<SB-SYS:IO-TIMEOUT {1003007811}>) 9: (ERROR SB-SYS:IO-TIMEOUT) 10: (SB-IMPL::REFILL-BUFFER/FD #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}>) 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> NIL :EOF) 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) #<unavailable argument> #<CHUNGA:CHUNKED-IO-STREAM {1002BE9B91}>) 13: ((SB-PCL::FAST-METHOD FLEXI-STREAMS::READ-BYTE* (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 14: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS::FLEXI-LATIN-1-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 15: (READ-CHAR #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> T NIL #<unused argument>) 16: (CHUNGA:READ-LINE* #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> NIL) 17: (HUNCHENTOOT::GET-REQUEST-DATA) 18: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {10038DFDB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 10 {1002771261}>) 19: ((LAMBDA ())) 20: ("foreign function: #x41EE32") 21: ("foreign function: #x416EF1")
-red
I have attached a patch that fixes the errors for me.
-red
red daly wrote:
This is a repeat of an earlier problem one user had, as documented in this thread: http://common-lisp.net/pipermail/tbnl-devel/2006-December/000876.html
Basically, mx explanation in the other email was right except for the logging part. There should /probably/ be some cleanup that prevents errors like this one (that aren't really errors) to pop up the debugger.
Maybe an intrigued soul will contribute a patch. The bug is more of an annoyance than anything.
The original email before I noticed it was a repeat report:
I have been noticing this IO error since several months ago. When catch-signals is nil, hunchentoot occasionally throws me into the debugger. It signals at seemingly random points during a server's lifetime.
I have a backtrace, but I do not know the source of the error.
I am running a 64 bit version of SBCL, though I have noticed this on 32 bit SBCL, too.
I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> [Condition of type SB-SYS:IO-TIMEOUT]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-79" {10027721A1}>)
Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {10067D6969}>) 1: (SWANK::DEBUG-IN-EMACS #<SB-SYS:IO-TIMEOUT {1003007811}>) 2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003007C19}>) 3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C39}>) 4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C19}>) 5: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 6: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 8: (SIGNAL #<SB-SYS:IO-TIMEOUT {1003007811}>) 9: (ERROR SB-SYS:IO-TIMEOUT) 10: (SB-IMPL::REFILL-BUFFER/FD #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}>) 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> NIL :EOF) 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) #<unavailable argument> #<CHUNGA:CHUNKED-IO-STREAM {1002BE9B91}>) 13: ((SB-PCL::FAST-METHOD FLEXI-STREAMS::READ-BYTE* (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 14: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS::FLEXI-LATIN-1-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 15: (READ-CHAR #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> T NIL #<unused argument>) 16: (CHUNGA:READ-LINE* #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> NIL) 17: (HUNCHENTOOT::GET-REQUEST-DATA) 18: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {10038DFDB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 10 {1002771261}>) 19: ((LAMBDA ())) 20: ("foreign function: #x41EE32") 21: ("foreign function: #x416EF1")
-red
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sun, 15 Apr 2007 19:37:05 -0700, red daly reddaly@gmail.com wrote:
I have attached a patch that fixes the errors for me.
Apart from this not being a patch against the latest release[1], it only applies to SBCL. I have a more general solution in mind which I'll release in the next days if I find some time.
Thanks, Edi.