Red Hat Bugzilla – Bug 223954
unwinding the context in signal handler fails
Last modified: 2007-11-30 17:07:40 EST
Description of problem:
When using sigaction to set a handler for SIGSEGV (including sa_flags |=
SA_SIGINFO), the man page for sigaction states that the third parameter of the
handler is actually ucontext_t*.
"man libunwind-ia64" states, that "unw_context_t is simply an alias for
ucontext_t". I would therefore assume that it is safe to use this context in the
signal handler to unwind the stack on IA64.
However, this does not seem to be working.
Version-Release number of selected component (if applicable):
compile an test case
Steps to Reproduce:
1.gcc 1.c -lunwind -ldl
unw_step fails with -6:
>Called with -Xtest=9999 causes me to crash, for test purposes.
>stack dump start (ucontext 0x60000fffffd4a8e0)
>unw_step failed rc = -6
>stack dump end
unwinding should work within the signal handler
Is the context intended for this use or do I need to get a new context with
Created attachment 146274 [details]
This has nothing to do with glibc, the ucontext_t * passed to signal handler
is set up by the kernel and the crash is in libunwind. Though, the fact that
signal handler is passed a pointer to the same structure as libunwind uses
doesn't mean necessarily that the kernel fills in all fields libunwind needs.
ok .. I was assuming that it is glibc related as the signal includes are
supplied by glibc :)
Anyway, does that mean that unw_context_t is n not compatible with ucontext_t or
just not in the signal handler case?
From 'man unw_getcontext':
On IA-64, unw_context_t has a layout that is compatible with that of ucontext_t
and such structures can be initialized with getcontext() instead of
unw_getcontext(). However, the reverse is not true and it is not safe to
use structures initialized by unw_getcontext() in places where a structure
initialized by getcontext() is expected.
I therefore assumed that the ucontext_t* passed is safe to use for unwinding.
So what is there a preferred/official way to do unwinding in the signal handler
(like using unw_getcontext to get a context) or should the provided context in
the signal handler be usable after all?
Created attachment 146386 [details]
Fix/workaround for the kernel signal frames unwinding.
So far it looks to me more as a kernel bug and this patch is only a workaround.
For debugging you may find useful a trivia debugging fix in Bug 224097.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
On Fri, 26 Jan 2007 16:05:50 +0100, David Mosberger-Tang wrote:
I'm afraid what Oliver is trying to do can't really work. The ia64
linux book actually goes into a fair amount of detail on this topic,
but the quick summary is that a signal-context cannot be used to
initialize an unwind-context. The proper way to do this is to either
create do an unw_get_context() in the signal handler or to initiate
unwinding at the inner-most frame and then do unw_step() until the
signal handler is reached (both methods are described with examples in
The reason you can't unwind directly out of a signal context is
because the kernel optimizes for speed and doesn't save any
"preserved" (callee-saved) registers in the signal context.
Mails should show up shortly on:
Referenced paper book: http://www.lia64.org/book/