Hi, On 2019-05-24 12:08:57 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-05-24 11:34:58 -0400, Tom Lane wrote: > >> Hmm, after some digging in the archives, the closest thing I can find > >> is this thread: > >> https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpWtrRZNey7hJ07%2BzT4bYJdVp4Szdrg%40mail.gmail.com > >> where we discussed using libunwind instead, but people didn't like > >> the extra dependency. > > > Hm, I didn't actually see that much concern about that. I still think we > > should just go for libunwind. > > Is it actually better?
I've not looked in a while, but I think at some point it was. > 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. Does that depend on whether the program was compiled with -fno-omit-frame-pointer? At least some distros now compile with frame pointers enabled, to get reasonably fast perf profiles (at a basically immeasurable slowdown, on modern-ish CPUs). > 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. It's still a lot easier to install debug symbols than to attach a debugger and get a backtrace that way. Especially when the problem is hard to reproduce. Greetings, Andres Freund
