Re: Printing backtrace of postgres processes
От | Ashutosh Bapat |
---|---|
Тема | Re: Printing backtrace of postgres processes |
Дата | |
Msg-id | CAExHW5uN3BJmsJzXDtcaooFgRkUeMs0wpprUwmY1pWZZ4ndv4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Printing backtrace of postgres processes (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Printing backtrace of postgres processes
|
Список | 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
В списке pgsql-hackers по дате отправления: