Hi, > According to the opinion of few people: > Backtrace is not a async_signal_safe and hence shouldn't be used inside > signal handler.
If you mean the linux glibc backtrace() implementation, then as far as I know the advice you've received is correct. The libunwind implementation, unw_backtrace() also aliased as backtrace(), is largely async safe; there are still issues with signals received during specific points in dynamic loading, but fortunately it is rare to hit those. If your purpose is to dump a stack on crash, it's unlikely you'll ever trigger the race. > also, again depends on the compile options of system library routines. if > those libraries are compiled with -fomit-frame-pointer option then, it is not > possible the unwind the stack as due to optimization frame pointer is not > stored on the stack. This I doubt. I've not seen a x64 tool chain which still uses a traditional frame pointer chain. Unwinding on x64 is done using unwind tables, not by frame pointer chain. AFAIK gcc defaults to -fomit-frame-pointer on x64, so everything on your system is built that way normally. Normally your compiler should automatically generate the required unwind info for everything, including languages like C which don't use exceptions. There are however problems with x64 unwind info *accuracy*. GCC versions prior to 4.5.x frequently generate incorrect unwind info, and some residual errors with SSE were fixed in later patch sets. If you have system libraries (libc, libm, libpthreads, etc.) built with older compiler, the inaccuracy problem is wide-spread. These do often result in inability to trace a stack. Normally you'll just get a truncated stack trace when this happens, but in some cases libunwind can crash (you can write your libunwind calls such that it protects you from the crashes; I'd recommend doing this if your use is for crash dumps). If you have the inaccuracy problem, then GDB will show equally poor stack trace. Usually you'll see the stack just one or two levels above the signal frame. The only cure for this is to rebuild the relevant code with a more recent compiler. For system libraries that means upgrading to more recent distribution, unfortunately. > How does libunwind library do backtrace internally? It uses the DWARF unwind info emitted by compilers into executables and shared libraries. > Could you please tell me the correct version of libunwind for linux x86_64, > so that I will try libunwind api's for the purpose. See Arun's reply, please try 1.0-rc1. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
