Re: more backtraces - Mailing list pgsql-hackers

From Andres Freund
Subject Re: more backtraces
Date
Msg-id 20191204195915.5epig6xl2wksibga@alap3.anarazel.de
Whole thread Raw
In response to more backtraces  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: more backtraces  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: more backtraces  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2019-12-04 20:45:25 +0100, Peter Eisentraut wrote:
> In the previous discussions on backtrace support, some people asked for
> backtraces in more situations.  Here is a patch that prints backtraces on
> SIGABRT, SIGBUS, and SIGSEGV signals.  SIGABRT includes assertions and
> elog(PANIC).

Hm. Can we really do that somewhat reliably like this? I'd suspect that
there'll be some oddities e.g. for stack overflows if done this way. To
my knowledge it's not a good idea to intercept SIGBUS/SIGSEGV without
using a separate signal stack (cf. sigaltstack) - but using a separate
stack could also make it harder to determine a correct backtrace?

It'd be bad if the addition of backtraces for SEGV/BUS suddenly made it
harder to attach a debugger and getting useful results. Even
disregarding the previous concerns, we'll get less useful debugger
interactions due to this, e.g. for things like null pointer derefs,
right?

Doing this for SIGABRT seems like a more clearly good case - by that
point we're already removed a few frames from the triggering code
anyway. So debugging experience won't suffer much. And I don't think
there's a corresponding issue with the stack potentially being
corrupted / not large enough.

- Andres



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: more backtraces
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Block level parallel vacuum