SIGSEGV at shutdown (was: Re: your mail)

Eric Wong normalperson at yhbt.net
Thu Jan 24 09:52:20 UTC 2013


Charles Hornberger <charles.hornberger at gmail.com> wrote:
> On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > Charles Hornberger <charles.hornberger at gmail.com> wrote:
> >> E, [2013-01-18T17:54:21.502915 #59285] ERROR -- : reaped
> >> #<Process::Status: pid 59288 SIGSEGV (signal 11)> worker=1

<snip>

> >> I, [2013-01-18T17:54:21.605077 #59285]  INFO -- : master complete
> >>
> >> Just wondering if it's something I should be concerned about? I saw no
> >> obvious symptoms of problems before or after…
> >>
> >> We currently restart unicorn (which is on a freebsd jail) like so:
> >
> > A SEGV at shutdown is likely an ordering problem at VM shutdown
> > (probably GC/finalization handling).  It could be specific to the
> > malloc/pthread implementation on FreeBSD, even.
> >
> > Which version of Ruby are you using?
> 
> 1.9.3p-125

Can you give 1.9.3-p374 a try?  There were several GC-related segfault
fixes along the way (fairly large and drastic changes, even).

<snip>

Nothing else jumps out at me (I remember nokogiri having a problem
which led to at least one GC bugfix shortly after p125).


Also, did you manage to get any backtrace from Ruby at all?  The Ruby VM
should show a partial stack trace on SEGV (or at least attempt to, but
it may not during shutdown).  Otherwise, you'd have to get gdb-able core
dumps the old-fashioned way (ulimit -c unlimited) and show us (or
ruby-core) the backtrace.


More information about the mongrel-unicorn mailing list