fukamachi / woo

A fast non-blocking HTTP server on top of libev
http://ultra.wikia.com/wiki/Woo_(kaiju)
MIT License
1.28k stars 98 forks source link

Issue with serving images (png?) in caveman2 with woo #41

Closed ahungry closed 8 years ago

ahungry commented 8 years ago

When I load my project (https://github.com/ahungry/sluglisp) via:

 sbcl --eval '(ql:quickload :sluglisp)' --eval '(sluglisp:start :port 60333 :server :woo)

Then visit my page at http://sluglisp.ahungry.com

The second png image (http://sluglisp.ahungry.com/images/made-with-lisp-small.png) fails to load and the browser sits there timing out.

When I cancel the http request, then re-request the page, sbcl reports this error:

debugger invoked on a TYPE-ERROR in thread
#<THREAD "clack-handler-woo" RUNNING {1005BEE223}>:
  The value -60356 is not of type (UNSIGNED-BYTE 64).

It only happens when running with :server :woo, using hunchentoot causes no issue.

The environment is CentOS 6.7 (final), with libev 4.0.0 present on the system.

All dependencies are up to date with Quicklisp latest.

This error happens across the board with any of my recent caveman2 projects when running under woo.

ahungry commented 8 years ago

If that project has too much to it, I'll try to put together a minimum working example later this week to help pinpoint reproducible steps.

fukamachi commented 8 years ago

Could you give me the stack traces when the error occurred?

sabracrolleton commented 8 years ago

Running into the same problem. Only hapens on on woo, not on hunchentoot. Executing from repl with libev 4.20-1 on an Arch linux system. Consistently the first call to a page is fine. The second call results in the failure to completely load and the browser sits there timing out. The welcome to caveman2 message shows up, but not the css file. Stopping and restarting the browser will again be fine. Refreshing the browser will again trigger the failure to fully load.

Only difference is that while I had a series of type-errors at one point, the same as ahungry, but after restarting my sbcl instance I have not been able to reproduce the type-error again. (The failure to fully load problem continues - first call fine, second call fail.) The only stack trace I grabbed during the series of type-errors was the last call: The value -407 is not of type (UNSIGNED-BYTE 64). Restarts: 0: [ABORT] abort thread (#<THREAD "clack-handler-woo" RUNNING {10094CACE3}>)

0: (WOO.SYSCALL::%SENDFILE 11 12 #.(SB-SYS:INT-SAP #X7FFFF0A5FFF0) -407)

fukamachi commented 8 years ago

Thanks. I got it. I think it may be fixed in fix-sendfile branch. Could you retry with it?

ahungry commented 8 years ago

Branch fixes it for me, I can't reproduce the failure.

Thanks!

sabracrolleton commented 8 years ago

Branch fixes it for me as well. Thank you.