From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-09 08:13:44 |
Message-ID: | ZcXeuOl9qy7YA9RH@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 08, 2024 at 12:25:18PM +0900, Michael Paquier wrote:
> In HandleLogBacktraceInterrupt(), we don't use backtrace_symbols() and
> rely on backtrace_symbols_fd() to avoid doing malloc() in the signal
> handler as mentioned in [1] back in 2022. Perhaps the part about the
> fact that we don't use backtrace_symbols() should be mentioned
> explicitely in a comment rather than silently implied? That's
> a very important point.
This has been itching me, so I have spent more time reading about
that, and while browsing signal(7) and signal-safety(7), I've first
noticed that this is not safe in the patch:
+ write_stderr("logging current backtrace of process with PID %d:\n",
+ MyProcPid);
Note that there's a write_stderr_signal_safe().
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-02-09 08:19:49 | Re: glibc qsort() vulnerability |
Previous Message | Peter Smith | 2024-02-09 08:12:35 | Re: Synchronizing slots from primary to standby |