I've finally figured out why c-stack is being finicky on Irix 5.3 [1]. POSIX
requires that sigaltstack be given ss_sp pointing to the smallest address in
the alternate stack. But Irix is non-compliant, and treats ss_sp as the
starting address of the stack (which, since it grows down, makes it the largest
address in the stack). From their man page for sigaltstack:
The stack grows downward from high to lower addresses. The following
code fragment is typically used to allocate an alternate stack.
if ((sigstk.ss_sp = (char *)malloc(SIGSTKSZ)) == NULL)
/* error return */;
sigstk.ss_sp += SIGSTKSZ - 1;
/* adjust ss_sp to point to base of stack */
sigstk.ss_size = SIGSTKSZ;
This explains why Tom and I were having such a hard time in debugging c-stack
code - the stack overflow handler was often triggering a secondary SIGSEGV as
it traversed outside the bounds of the alternate stack, because we were setting
up the alternate stack with the wrong bound per Irix conventions.
Before m4 was converted over to use c-stack, m4's stackovf.c worked around this
issue by allocating 2*SIGSTKSZ bytes, then passing the midway point of the
overallocation to sigaltstack, compared to c-stack's current approach of just
allocating SIGSTKSZ bytes. I'm debating about using the same workaround, or
whether it is worth trying to write a configure-time test that checks for which
side of the alternate stack is visited first in order add #ifdefs to set ss_sp
correctly and avoid allocating the extra SIGSTKSZ bytes. Any preferences?
Bruno, this means that libsigsegv 2.6 is buggy in handling sigsegv on platforms
like Irix 5.3 (even though the tests currently pass, it is by sheer luck,
because you are corrupting the contents of the stack outside of the area
reserved for your stack-allocated alternate stack). Maybe you should make the
stackoverflow1.c test be more robust, by allocating some stack variables on
either side of the alternate stack, setting them to known patterns, and
checking that they have not been corrupted when longjmp'ing back out of the
overflow handler. Or maybe add a test that mmap's the alternate stack, such
that exceeding the bounds of the alternate stack will indeed cause a definite
segv, rather than a luck-of-the-draw clobbering of unrelated but allocated
memory.
[1] http://lists.gnu.org/archive/html/bug-m4/2008-09/msg00014.html
--
Eric Blake
