Re: Workers reaped with SIGABRT - how to debug?

2014-04-28 Thread Eric Wong
Henrik Nyh hen...@barsoom.se wrote: It was simply that monit did a kill -6 (SIBABRT) when the process used too much memory, so we bumped that limit for now. D'oh. We've yet to research why it used that much memory. Thanks for the followup. Unfortunately the RGenGC in Ruby 2.1.x uses more

Re: Workers reaped with SIGABRT - how to debug?

2014-04-16 Thread Henrik Nyh
Henrik, we had the same problem after upgrading to Ruby 2.1.1. My coworker Tieg Zaharia tracked it down to this bug with BigDecimal#to_d: https://bugs.ruby-lang.org/issues/9657 He discusses a workaround (using BigDecimal coercion instead of #to_d). Worked for us. Thank you! We'll look

Re: Workers reaped with SIGABRT - how to debug?

2014-04-15 Thread Eric Wong
Henrik Nyh hen...@barsoom.se wrote: We get errors like this one a few times a day: Apr 13 12:16:31 app1 unicorn.log: E, [2014-04-13T12:16:31.302011 #17269] ERROR -- : reaped #Process::Status: pid 17300 SIGABRT (signal 6) worker=2 We use Unicorn 4.8.2, Ruby 2.1.1 and a Ruby on Rails

Re: Workers reaped with SIGABRT - how to debug?

2014-04-15 Thread Henrik Nyh
On Tue, Apr 15, 2014 at 10:43 AM, Eric Wong normalper...@yhbt.net wrote: This is may be a bug in a C extension RubyGem or even Ruby itself. Do you get core dumps + backtraces or any other error messages in the logs? You'd expect this to be in the Rails app's production.log, right? We added that