Re: c-stack vs. older platforms

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> and Linux glibc 2.3.4, I noticed that config.h's 

and kernel 2.6.9,

> HAVE_XSI_STACK_OVERFLOW_HEURISTIC was undefined with c-stack, so it seems 
like 
> _any_ segv, rather than true overflows, would be reported on those platforms 
(I 
> guess I'll have to enhance and rerun my tests with an intentional non-
overflow 
> segv to verify).  Or maybe c-stack.m4's test case is too restrictive.
> 
> > 
> >   - But the most constraining requirement is how to get the fault address:
> >       - 'ip->si_addr' works only on
> >           Linux >= 2.4, HP-UX, OSF/1, Solaris.
> >         (The same code would also work on FreeBSD, NetBSD, OpenBSD if you
> >         were catching SIGBUS in addition to SIGSEGV.)

This is one place where m4's implementation was better than c-stack.  Right 
now, I'm debugging c-stack on a Linux kernel 2.6.9.  Right after the segv 
fault, ip->si_addr correctly contains the first access that exceeded the stack 
boundary, at 0xbf3fff78, but user_context->uc_stack.ss_sp contains the location 
of the currently running (alternate) stack, not the stack where the fault 
occurred.  The c-stack code is checking whether the faulting address lies 
anywhere near 0x0806c240, whereas m4 was at least trying to see if the fault 
was within a window of the predetermined original stack!  No wonder the 
HAVE_XSI_STACK_OVERFLOW_HEURISTIC fails on Linux - c-stack isn't correctly 
dereferencing the context structure to find out where the _original_ stack 
ended, and the faulting address is nowhere near the end of the alternate 
stack.  Which means c-stack is blindly treating _all_ segv as stack overflow.

Unfortunately, I'm not sure if c-stack can be easily repaired.  Looking 
further, user_context->uc_link, which is described in POSIX as being a pointer 
to the next context (if/when this alternate context returns), is NULL.  In 
other words, I think m4's approach is the only way to learn where the original 
stack ended, and that approach was failing on Linux since m4 was guessing the 
wrong end-of-stack.

I haven't looked at how libsigsegv handles this situation, to see what else 
might be done on Linux to properly learn if ip->si_addr falls near the end of 
the original (and not alternate) stack.

-- 
Eric Blake