Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Balamurugan Mahendran <balamurugan(at)adaptavant(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Date: 2010-11-27 09:23:34
Message-ID: 4CF0CE16.90402@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 27/11/2010 5:09 PM, Balamurugan Mahendran wrote:

> Program received signal SIGQUIT, Quit.

That's a signal 3 (SIGQUIT). You said you were getting signal 11
(SIGSEGV) crashes. Are you sure this is the same thing?

I suspect you've connected to one of the other backends, not the backend
that actually crashes. You need to identify which one gets the SIGSEGV.
It may be a short-lived autovacuum worker, in which case you'll have a
hard time getting gdb attached to it before it goes splat.

If you do manage to get gdb connected to the crashing backend, instead
of just continuing after gdb pauses at the fatal signal (SIGSEGV), type
at the (gdb) prompt:

bt

then press enter.

You may instead want to enable core dumps as per the instructions on the
same page:

http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

... then run gdb on the core dump after the crash. That can potentially
be easier if the crashing backend isn't the one doing the COPY.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Craig Ringer 2010-11-27 09:25:37 Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Previous Message Balamurugan Mahendran 2010-11-27 09:09:01 Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme