Re: Async-unsafe functions in signal handlers

As far as I understand, the main problem with backtrace_symbols() is the internal malloc() call. Backend can lock
foreverif malloc() was interrupted by a signal and then was evaluated again in a signal handler. 

At the moment Greenplum uses "addr2line -s -e» (on Linux) and "atos -o" (on macOS) for each stack address instead of
backtrace_symbols().Both of these utils don’t use malloc() underhood, although there is no guarantee that this
implementationnever changes in the future. It seems to be a safer approach, but looks like a dirty hack. 

> 26 авг. 2021 г., в 08:52, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
>
>
>> 25 авг. 2021 г., в 19:22, Denis Smirnov <sd@arenadata.io> написал(а):
>>
>> I am going to refactor Greenplum backtraces for error messages and want to make it more compatible with PostgreSQL
code.Backtraces in PostgreSQL were introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original discussion
https://www.postgresql.org/message-id/CAMsr+YGL+yfWE=JvbUbnpWtrRZNey7hJ07+zT4bYJdVp4Szdrg@mail.gmail.com) and rely on
backtrace()and backtrace_symbols() functions. They are used inside errfinish() that is wrapped by ereport() macros.
ereport()is invoked inside bgworker_die() and FloatExceptionHandler() signal handlers. I am confused with this fact -
bothbacktrace functions are async-unsafe: backtrace_symbols() - always, backtrace() - only for the first call due to
dlopen.I wonder why does PostgreSQL use async-unsafe functions in signal handlers? 
>
> In my view GUC backtrace_functions is expected to be used for debug purposes. Not for enabling on production server
forbgworker_die() or FloatExceptionHandler(). 
> Are there any way to call backtrace_symbols() without touching backtrace_functions?
>
> Best regards, Andrey Borodin.
>

Best regards,
Denis Smirnov | Developer
sd@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia