Hi,
On 2020-11-22 01:25:08 -0500, Tom Lane wrote:
> Surely this is *utterly* unsafe. You can't do that sort of stuff in
> a signal handler.
That's of course true for the current implementation - but I don't think
it's a fundamental constraint. With a bit of care backtrace() and
backtrace_symbols() itself can be signal safe:
> backtrace() and backtrace_symbols_fd() don't call malloc() explicitly,
> but they are part of libgcc, which gets loaded dynamically when first
> used. Dynamic loading usually triggers a call to malloc(3). If you need
> certain calls to these two functions to not allocate memory (in signal
> handlers, for example), you need to make sure libgcc is loaded beforehand.
It should be quite doable to emit such backtraces directly to stderr,
instead of using appendStringInfoString()/elog(). Or even use a static
buffer.
It does have quite some appeal to be able to debug production workloads
where queries can't be cancelled etc. And knowing that backtraces
reliably work in case of SIGQUIT etc is also nice...
> I would like to see some discussion of the security implications
> of such a feature, as well. ("There aren't any" is the wrong
> answer.)
+1
Greetings,
Andres Freund
