[PATCH 4/5] Support backtracing through elfutils (#70746)

[Jan Kratochvil]

On Thu, 31 Oct 2013 10:55:09 +0100, Mark Wielaard wrote:
> On Thu, 2013-10-31 at 14:00 +1000, Peter Hutterer wrote:
> > and yes, xorg_backtrace() is almost always called from within the signal
> > handler.
> 
> In that case, the process is crashing, possibly corrupted and inside a
> signal handler, I am not sure you really want to do in-process
> backtracing and symbol lookup. You might want to let the OS catch it (or
> divert to gdb, abrt, dump core, etc.). IMHO getting the backtrace and
> printing whatever you can through the standard glibc library might be
> simplest and safest. Anything more might not be very safe at that point.

Calling backtrace() for the first time also is not signal-safe:
glibc/sysdeps/x86_64/backtrace.c init() calls __libc_dlopen().
Maybe xorg could call backtrace() just during init to get backtrace()
initialized, I am not completely sure it will be signal-safe then but it may be.

To get .symtab symbols resolution the only safe way is to do fork()+exec().
You can either execute GDB :-) or some small helper app.  Just the other app
can no longer call just backtrace() so you need a real "remote" unwinder.
THe options are GDB, libunwind, next elfutils (not current elfutils).

(There will be "/usr/bin/eu-stack -p PID" in next elfutils but sure one can
code such a simple app also based on libunwind.)

/usr/bin/gstack and /usr/bin/pstack is just a script using GDB so that is not
a win if you try to avoid GDB for whatever reason.


Regards,
Jan