Philipp Bruell <[email protected]> wrote:
> On 01/02/2012 19:14, "Eric Wong" <[email protected]> wrote:
> >Philipp Bruell <[email protected]> wrote:
> The scripts behaves exactly like unicorn. The master received the QUIT and
> passes it to the child. The child also receives it, but don't exit. While
> the master is waiting for the child to exit, it consumes all the cpu
> cycles.
Interesting, I suspect it's some bad interaction with fork() causing
signal handlers/pthreads to go bad. I expect the following simple
script to work flawlessly since it doesn't fork:
----------------------------------------
trap(:QUIT) { exit(0) }
puts "Ready for SIGQUIT on #$$"
sleep
----------------------------------------
> I don't have the option, to test without jail, on a different FreeBSD
> version nor a different architecture (and FreeBSD - on Mac OS X everything
> works perfect). But I tried ruby version 1.9.2 and that works! So I guess
> it's a bug with 1.9.3 on FreeBSD.
Can you report this as a bug to the Ruby core folks on
https://bugs.ruby-lang.org/ and also to whereever the FreeBSD hackers
take bug reports? Somebody from one of those camps should be able
to resolve the issue.
The good thing is my small sample script is enough to reproduce the
issue, so it should be easy for an experienced FreeBSD hacker to
track down.
> I've attached the truss -f output of the child process of the test script.
> But the observation with truss made the problem disappear again :-(
It could be a timing or race condition issue. I've had strace on linux
find/hide bugs because it slowed the program down enough.
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
