Caveman crashes occasionally

[triclops200]

Every once and a while caveman crashes with a simple stream error stating that the stream ended abruptly. Can force it to happen by holding down the f5 key.

[fukamachi]

Needs more information.

• Web server the app running on
• The name of your Common Lisp implementation and its version
• The value of :debug option when you started the app

[triclops200]

Hunchentoot

Sbcl 1.2.13

Nil

[fukamachi]

Will you check if it happens when you use Hunchentoot directly?

On Thu, Jul 16, 2015 at 6:22 PM, Bryan Hoyle notifications@github.com wrote:

Hunchentoot Sbcl 1.2.13

Nil

Reply to this email directly or view it on GitHub: https://github.com/fukamachi/caveman/issues/66#issuecomment-121897193

[triclops200]

How would I do that? I haven't used hunchentoot before. On Jul 16, 2015 06:15, "Eitaro Fukamachi" notifications@github.com wrote:

Will you check if it happens when you use Hunchentoot directly?

On Thu, Jul 16, 2015 at 6:22 PM, Bryan Hoyle notifications@github.com wrote:

Hunchentoot Sbcl 1.2.13

Nil

Reply to this email directly or view it on GitHub: https://github.com/fukamachi/caveman/issues/66#issuecomment-121897193

— Reply to this email directly or view it on GitHub https://github.com/fukamachi/caveman/issues/66#issuecomment-121917450.

[triclops200]

[2015-07-16 07:30:30 [ERROR]] Error while processing connection: Couldn't write to #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:36213" {100A0345F3}>: Broken pipe Is the error that causes the crash on my server with caveman, but, locally, the server stays running. They are both running the same software. (Sorry I couldn't get this earlier, I didn't have access to the error logs until now)

[triclops200]

Here is the full backtrace when the server crashes.

Backtrace for: #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:56103" RUNNING {1009FBA033}>
0: ((LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX))
1: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1004C3961B}>)
2: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1004C395EB}>)
3: (PRINT-BACKTRACE :STREAM #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {1000166063}> :START 0 :FROM :INTERRUPTED-FRAME :COUNT NIL :PRINT-THREAD T :PRINT-FRAME-SOURCE NIL :METHOD-FRAME-STYLE NIL)
4: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {1004BA2B53}> #<unavailable argument>)
5: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {1004BA2B53}>)
6: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {1004BA2B53}>)
7: ((:METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {1004BA2B53}>) [fast-method]
8: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {1004BA2B53}>)
9: (ERROR SB-INT:SIMPLE-STREAM-ERROR :STREAM #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}> :FORMAT-CONTROL "~@<~?: ~2I~_~A~:>" :FORMAT-ARGUMENTS ("Couldn't write to ~s" (#<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}>) "Broken pipe"))
10: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}> 32)
11: (SB-IMPL::FLUSH-OUTPUT-BUFFER #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}>)
12: (SB-IMPL::FINISH-FD-STREAM-OUTPUT #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}>)
13: (FINISH-OUTPUT #<SB-SYS:FD-STREAM for "socket 127.0.0.1:50000, peer: 127.0.0.1:56103" {1009CD5FF3}>)
14: (FINISH-OUTPUT #<CHUNGA:CHUNKED-IO-STREAM {10046E6733}>)
15: ((FLET HUNCHENTOOT::CLOSE-STREAM :IN HUNCHENTOOT:PROCESS-CONNECTION) #<CHUNGA:CHUNKED-IO-STREAM {10046E6733}>)
16: ((FLET #:CLEANUP-FUN-402 :IN HUNCHENTOOT:PROCESS-CONNECTION)) [cleanup]
17: ((:METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) #<HUNCHENTOOT:EASY-ACCEPTOR (host *, port 50000)> #<USOCKET:STREAM-USOCKET {1009D85CF3}>) [fast-method]
18: ((:METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) #<HUNCHENTOOT:EASY-ACCEPTOR (host *, port 50000)> #<USOCKET:STREAM-USOCKET {1009D85CF3}>) [fast-method]
19: ((FLET HUNCHENTOOT::PROCESS-CONNECTION% :IN HUNCHENTOOT::HANDLE-INCOMING-CONNECTION%) #<HUNCHENTOOT:EASY-ACCEPTOR (host *, port 50000)> #<USOCKET:STREAM-USOCKET {1009D85CF3}>)
20: ((LAMBDA NIL :IN BORDEAUX-THREADS::BINDING-DEFAULT-SPECIALS))
21: ((FLET #:WITHOUT-INTERRUPTS-BODY-1121 :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
22: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
23: ((FLET #:WITHOUT-INTERRUPTS-BODY-584 :IN SB-THREAD::CALL-WITH-MUTEX))
24: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE) {7FFFF1AA6C8B}> #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:56103" RUNNING {1009FBA033}>> NIL T NIL)
25: (SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:56103" RUNNING {1009FBA033}> NIL #<CLOSURE (LAMBDA NIL :IN BORDEAUX-THREADS::BINDING-DEFAULT-SPECIALS) {1009FB9FBB}> (#<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:56103" RUNNING {1009FBA033}> #1=#<SB-THREAD:THREAD "clack-handler-hunchentoot" RUNNING {1009935183}> #<SB-THREAD:THREAD "Hierarchy Watcher" RUNNING {100760C963}> #<SB-THREAD:THREAD "main thread" waiting on: #<MUTEX "thread result lock" owner: #1#> {1003EA6EF3}>) NIL NIL NIL NIL)
26: ("foreign function: call_into_lisp")
27: ("foreign function: new_thread_trampoline")

[triclops200]

Also, I got wookie working and wookie does not have the issue.

[ritschmaster]

I can confirm this. I have the exact same error, see here: https://github.com/ritschmaster/caveman2-widgets/issues/5

[spacebat]

I've been getting the same error whenever I disconnect while playing with server sent events in hunchentoot. Doing (setf hunchentoot:*catch-errors-p* t) prevents the debugger from being invoked and the error is caught and logged instead. Unfortunately it is unconditionally set to nil in clack.handler.hunchentoot::initialize, so you could patch that, or wrap it with something like:

(defvar *orig-initialize* #'clack.handler.hunchentoot::initialize)

(defun clack.handler.hunchentoot::initialize ()
  (funcall *orig-initialize*)
  (setf hunchentoot:*catch-errors-p* t))

[fukamachi]

@spacebat Thank you for letting me know the way to handle it.

This has been resolved in Clack.Handler.Hunchentoot. Please check it out with the latest Clack again.