Re: more backtraces

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: more backtraces
Дата
Msg-id 20191204195915.5epig6xl2wksibga@alap3.anarazel.de
обсуждение исходный текст
Ответ на more backtraces  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: more backtraces  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: more backtraces  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: more backtraces
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum