[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] is backtrace in Signal Handler possible on Linux x
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] is backtrace in Signal Handler possible on Linux x86_64? |
Date: |
Tue, 23 Aug 2011 11:31:02 +0300 |
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