From: Michael Paquier <michael@paquier.xyz>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
Date: Sat, 10 Feb 2024 09:06:35 +0900
Message-ID: <Zca-C0rND4V0ZWI6@paquier.xyz> (raw)
In-Reply-To: <CAExHW5ugP_fAXtZhyES4zW5OtYn8J5e=eDZbSCCVM2ekASQRSg@mail.gmail.com>
References: <ZcXeuOl9qy7YA9RH@paquier.xyz>
<202402090848.j6evnpunbehe@alvherre.pgsql>
<CAExHW5ugP_fAXtZhyES4zW5OtYn8J5e=eDZbSCCVM2ekASQRSg@mail.gmail.com>
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.
> 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.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../Zca-C0rND4V0ZWI6@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, ashutosh.bapat.oss@gmail.com, alvherre@alvh.no-ip.org, bharath.rupireddyforpostgres@gmail.com, vignesh21@gmail.com, torikoshia@oss.nttdata.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Printing backtrace of postgres processes
In-Reply-To: <Zca-C0rND4V0ZWI6@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox