As far as I understand, the main problem with backtrace_symbols() is the internal malloc() call. Backend can lock forever if 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 implementation never changes in the future. It seems to be a safer approach, but looks like a dirty hack. > 26 авг. 2021 г., в 08:52, Andrey Borodin <x4...@yandex-team.ru> написал(а): > > > >> 25 авг. 2021 г., в 19:22, Denis Smirnov <s...@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+zt4byjdvp4sz...@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 - both backtrace 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 for bgworker_die() or > FloatExceptionHandler(). > Are there any way to call backtrace_symbols() without touching > backtrace_functions? > > Best regards, Andrey Borodin. > Best regards, Denis Smirnov | Developer s...@arenadata.io Arenadata | Godovikova 9-17, Moscow 129085 Russia
