[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


> 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 

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 

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]