Re: Printing backtrace of postgres processes
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, vignesh C <vignesh21@gmail.com>, torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-09T08:48:36Z
Lists: pgsql-hackers
On 2024-Feb-09, Michael Paquier wrote:
> Anyway, I've been digging around the signal-safety of backtrace(3)
> (even looking a bit at some GCC code, brrr), and I am under the
> impression that backtrace() is just by nature not safe and also
> dangerous in signal handlers. One example of issue I've found:
> https://github.com/gperftools/gperftools/issues/838
>
> This looks like enough ground to me to reject the patch.
Hmm, but the backtrace() manpage says
• backtrace() and backtrace_symbols_fd() don't call malloc() explic‐
itly, but they are part of libgcc, which gets loaded dynamically
when first used. Dynamic loading usually triggers a call to mal‐
loc(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.
and the patch ensures that libgcc is loaded by calling a dummy
backtrace() at the start of the process.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"All rings of power are equal,
But some rings of power are more equal than others."
(George Orwell's The Lord of the Rings)
Commits
-
Perform apply of large transactions by parallel workers.
- 216a784829c2 16.0 cited
-
Enhance pg_log_backend_memory_contexts() for auxiliary processes.
- 790fbda90209 15.0 cited
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited
-
Move Perl test modules to a better namespace
- b3b4d8e68ae8 15.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited
-
Add backtrace support for error reporting
- 71a8a4f6e365 13.0 cited