Re: Printing backtrace of postgres processes
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-12T01:22:24Z
Lists: pgsql-hackers
On Sat, Feb 10, 2024 at 5:36 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote: > > On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > >> 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. > > FWIW, anything I am reading about the matter freaks me out, including > the dlopen() part in all the backends: > https://www.gnu.org/software/libc/manual/html_node/Backtraces.html > > So I really question whether it is a good idea to assume if this will > always be safe depending on the version of libgcc dealt with, > increasing the impact area. Perhaps that's worrying too much, but it > looks like one of these things where we'd better be really careful. I agree. We don't want a call to backtrace printing mechanism to make things worse. > > > We defer actual action triggered by a signal till CHECK_FOR_INTERRUPTS > > is called. I understand that we can't do that here since we want to > > capture the backtrace at that moment and can't wait till next CFI. But > > printing the backend can surely wait till next CFI right? > > Delaying the call of backtrace() to happen during a CFI() would be > safe, yes, and writing data to stderr would not really be an issue as > at least the data would be sent somewhere. That's less useful, but > we do that for memory contexts. Memory contexts do not change more or less till next CFI, but stack traces do. So I am not sure whether it is desirable to wait to capture backtrace till next CFI. Given that the user can not time a call to pg_log_backend() exactly, so whether it captures the backtrace exactly at when interrupt happens or at the next CFI may not matter much in practice. -- Best Wishes, Ashutosh Bapat
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