sigaltstack() + siglongjmp() breakage

From: David Mosberger <>
Date: 2004-08-24 03:31:56
Back in Feb 2002, we changed the kernel to spill the dirty partition
of the register stack onto the alternate signal stack rather than
spilling it onto the old stack.  This inadvertently broke
siglongjmp().  As a result, if you do a siglongjmp() out of a signal
handler which uses the alternate signal stack, it's possible (and
often likely) that the contents of register-backing store will be

Apparently, this isn't something that tons of programs do as nobody
seems to have complained so far.  I only discovered it when tracking
down a test-case failure in libc which only showed with libunwind;
GCC's built-in unwinder masks the bug for unrelated reasons.

Fixing this problem is of course very important but since it's rather
fundamental stuff, I'll need to test it carefully before posting a
patch.  For now, I just wanted to give a heads up in case somebody is
seeing failures in programs that use alternate signal stacks and

If you need a quick workaround, you could consider using the
setjmp/longjmp implementation that comes with libunwind [1] (it's in
library libunwind-setjmp).  This implementation doesn't suffer from
the problem described above, but, on the flip-side, you need fairly
current libraries and compilers to be sure that the unwind-info is
correct.  Without correct unwind-info, the libunwind implementation of
setjmp/longjmp would fail, of course.  Also, another thing to consider
is that with the libunwind-based implementation, setjmp() will be
extremely fast (just needs to store 3 words), but longjmp() will be
much slower (since the stack needs to be unwound).


To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Mon Aug 23 13:54:30 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:29 EST