Hi, On 2023-07-03 11:58:25 +0200, Alvaro Herrera wrote: > 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.
Yea. And I've grown pretty tired asking people to break out gdb in production scenarios :/ > > 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. It's often distributed as part of gcc. > For example, Debian seems to only have a package called android-libbacktrace > which I imagine is not what we want. Indeed not. > 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. We should be able to depend on that gcc-NN depends on libgcc-NN-dev, it contains all the compiler version specific stuff. It's where the intrinsics headers, C runtime initialization, sanitizer libraries all live. clang will typically also depend on libgcc-NN-dev on unixoid systems. And since it's statically linked (and needs to be apparently), you don't need libgcc-NN-dev installed at runtime. > I think it's pretty much the same in the RPM side of the world. I don't know much about that side of the world... Greetings, Andres Freund