Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 24, 2019 at 12:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Is it actually better? The basic problem with backtrace() is that it
>> only knows about global functions, and so reports call sites in static
>> functions as if they were in whatever global function physically precedes
>> the static one. I think doing materially better requires depending on
>> debug symbols, which (at least in the Red Hat world) aren't going to
>> be there in a typical production situation.
> I don't have an opinion on glibc vs. libunwind, but I don't understand
> this argument. If you are unlucky enough to have a production server
> that is crashing due to some hitherto-unknown bug, and if it's not
> possible to get a good backtrace without installing debugging symbols,
> then you are going to have to pick between (1) installing those
> debugging symbols and (2) getting a poor backtrace. I don't really
> see that as a problem so much as just the way life is.
Well, it *is* a problem. The whole point of this discussion I think is
to try to get better information "by default" for routine bug reports.
So if those come from production servers without debug symbols, which
I believe will be the usual case, then it seems likely to me that
libunwind will produce no better results than glibc. (But perhaps
I'm wrong about that --- I have not experimented with libunwind.)
Now it's true that "install debug symbols" is less of an ask than
"install debug symbols, *and* gdb, and make sure server core dumps are
enabled, and then go through this arcane manual procedure next time
you get a core dump". But we shouldn't fool ourselves that it isn't
an ask that's going to be hard for people with corporate policies
against installing extra stuff on production servers.
regards, tom lane