Re: Optionally using a better backtrace library?

Hello,

On 2023-Jul-02, Andres Freund wrote:

> I like that we now have a builtin backtrace ability. Unfortunately I think the
> backtraces are often not very useful, because only externally visible
> functions are symbolized.

Agreed, these backtraces are pretty close to useless. Not completely,
but I haven't found a practical way to use them for actual debugging
of production problems.

> I hacked it up for ereport() to debug something, and the backtraces are
> considerably better:
>
> 2023-07-02 10:52:54.863 PDT [1398207][client backend][:0][[unknown]] LOG: will crash
> 2023-07-02 10:52:54.863 PDT [1398207][client backend][:0][[unknown]] BACKTRACE:
> [0x55fcd03e6143] PostgresMain: ../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c:4126
> [0x55fcd031154c] BackendRun: ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4461
> [0x55fcd0310dd8] BackendStartup: ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4189
> [0x55fcd030ce75] ServerLoop: ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1779

Yeah, this looks much more usable.

> Nice things about libbacktrace are that the generation of stack traces is
> documented to be async signal safe on most platforms (with a #define to figure
> that out, and a more minimal safe version always available) and that it
> supports a wide range of platforms:

Sadly, it looks like the library is seldom distributed. For example,
Debian seems to only have a package called android-libbacktrace which I
imagine is not what we want. On my system I see a static library only
-- is that enough? That file is part of package libgcc-10-dev, which
tells me that we can't depend on that for packaging purposes.

I think it's pretty much the same in the RPM side of the world.

So the only way to get this into customer systems would be to include
the library in our packages.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem." (Tom Lane)