Re: Printing backtrace of postgres processes

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Printing backtrace of postgres processes
Date: 2024-02-12 01:22:24
Message-ID: CAExHW5uN3BJmsJzXDtcaooFgRkUeMs0wpprUwmY1pWZZ4ndv4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 10, 2024 at 5:36 AM Michael Paquier <michael(at)paquier(dot)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(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-02-12 02:27:14 Re: Add semi-join pushdown to postgres_fdw
Previous Message Michael Paquier 2024-02-12 00:10:45 Re: GUC-ify walsender MAX_SEND_SIZE constant