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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
