Re: more backtraces

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: more backtraces
Date: 2019-12-04 19:59:15
Message-ID: 20191204195915.5epig6xl2wksibga@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-12-04 20:11:04 Re: [HACKERS] Block level parallel vacuum
Previous Message Peter Eisentraut 2019-12-04 19:45:25 more backtraces