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
