Hey, i checked out the revision 26253 built it and ran it and it seems to work again but: I didn't build it via FreeBSD ports so there might be a difference in configure / build options and I checked out the revision which included the change you suspect for causing the issue so I'm not sure if thats really helping us. Curling directly unicorn works without truncation and issues though.
Kind regards, John On 04.02.2010, at 13:26, John-Paul Bader wrote: > Hey again, > > I will try to compile build the svn revision and let you know. I have to do > some other work before that so I will report back in the evening (CEST / > BERLIN) > > Thank you for helping out, kind regards, > > John > > On 04.02.2010, at 11:11, Eric Wong wrote: > >> John-Paul Bader <[email protected]> wrote: >>> One more, >> >> Hi, >> >> About the exceptions, looks like you had '-d' (debug) instead of '-D' >> (daemonize) so it spewed every exception (even if trapped) to stderr. >> EAGAIN is common when dealing with non-blocking sockets. Most of that >> is noise... >> >> However the EINVAL in unicorn/http_response.rb is suspect. >> >>> I reproduced the upgrading on my staging server which was still at the >>> old state in terms of software. I started by upgrading ruby from >>> >>> ruby+nopthreads-1.8.7.160_5,1 -> ruby+nopthreads-1.8.7.248,1 >>> ruby18-iconv-1.8.7.160,1 -> ruby18-iconv-1.8.7.248,1 >>> >>> And voilá - the very same problems. So now I'm like what? >>> >>> Is this rather a ruby than a unicorn issue ? Couldn't find any clues >>> in the changelog so far: >>> http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_8_7_248/ChangeLog >> >> That should narrow it down, so I start reading diffs from >> v1_8_7_160..v1_8_7_248 ... >> >> Does backporting the following change in ruby_1_8 >> (but not yet in the ruby_1_8_7 branch) fix things for you? >> >> commit 841a57341ed43f5fa86489c12aceb25a232be820 >> Author: nobu <n...@b2dd03c8-39d4-4d8f-98ff-823fe69b080e> >> Date: Fri Jan 8 09:51:23 2010 +0000 >> >> * io.c (io_fwrite): preserve errno. [ruby-core:27425] >> >> >> git-svn-id: http://svn.ruby-lang.org/repos/ruby/branches/ruby_...@26253 >> >> (snipped) >> >> diff --git a/io.c b/io.c >> index 375cbc8..d4d28e5 100644 >> --- a/io.c >> +++ b/io.c >> @@ -122,6 +122,9 @@ extern void Init_File _((void)); >> # endif >> #endif >> >> +#define preserving_errno(stmts) \ >> + do {int saved_errno = errno; stmts; errno = saved_errno;} while (0) >> + >> VALUE rb_cIO; >> VALUE rb_eEOFError; >> VALUE rb_eIOError; >> @@ -490,7 +493,7 @@ io_fwrite(str, fptr) >> r = write(fileno(f), RSTRING(str)->ptr+offset, l); >> TRAP_END; >> #if BSD_STDIO >> - fseeko(f, lseek(fileno(f), (off_t)0, SEEK_CUR), SEEK_SET); >> + preserving_errno(fseeko(f, lseek(fileno(f), (off_t)0, SEEK_CUR), >> SEEK_SET)); >> #endif >> if (r == n) return len; >> if (0 <= r) { >> --- >> Of course, the original reason for this fseeko() was to fix another >> problem Unicorn exposed when mixing stdio + unistd calls... >> >> http://redmine.ruby-lang.org/issues/show/2267 >> >> -- >> Eric Wong >> _______________________________________________ >> Unicorn mailing list - [email protected] >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >> Do not quote signatures (like this one) or top post when replying >> > > _______________________________________________ > Unicorn mailing list - [email protected] > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying > _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
