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): glibc-2.5-4 gcc-4.1.1-43.el5 How reproducible: compile an test case Steps to Reproduce: 1.gcc 1.c -lunwind -ldl 2. 3. Actual results: 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 >Segmentation fault Expected results: unwinding should work within the signal handler Additional info: Is the context intended for this use or do I need to get a new context with unw_getcontext? Regards, Oliver
Created attachment 146274 [details] test case
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.
Hi, 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': <quote> 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. </quote> 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? Regards, Oliver
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 inclusion.
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 book). 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: http://lists.gnu.org/archive/html/libunwind-devel/2007-01/ Referenced paper book: http://www.lia64.org/book/