> I'm still mystified as to how a package which uses automatic variables
> to deal with a stack overflow situation could claim to be handling stack
> overflow.
It's all in how Windows generates the stack overflow SEH fault. The comments
in libsigsegv/src/handler-win32.c are pretty clear:
/* Stack overflow handling is tricky:
First, we must catch a STATUS_STACK_OVERFLOW exception. This is signalled
when the guard page at the end of the stack has been touched. The operating
system remaps the page with protection PAGE_READWRITE and only then calls
our exception handler. Actually, it's even more complicated: The stack has
the following layout:
| |guard|----------stack-----------|
and when the guard page is touched, the system maps it PAGE_READWRITE and
allocates a new guard page below it:
| |guard|-------------stack--------------|
Only when no new guard page can be allocated (because the maximum stack
size has been reached), will we see an exception.
|guard|-------------------------stack--------------------------|
Second, we must reinstall the guard page. Otherwise, on the next stack
overflow, the application will simply crash (on WinNT: silently, on Win95:
with an error message box and freezing the system).
But since we don't know where %esp points to during the exception handling,
we must first leave the exception handler, before we can restore the guard
page. And %esp must be made to point to a reasonable value before we do
this.
Note: On WinNT, the guard page has protection PAGE_READWRITE|PAGE_GUARD.
On Win95, which doesn't know PAGE_GUARD, it has protection PAGE_NOACCESS.
*/
Basically, by the time SEH wakes you up to tell you about stack overflow, the
guard page is now read-write, so you effectively have an entire page of memory
(but no more) in which to do all your management of setting up an alternate
stack. The automatic variables within libsigsegv's SEH handler occupy only a
bounded amount of stack depth within the guard page to restart execution, but
using stk_extra_stack (which was either carved out of the original stack via
alloca, or carved out of the heap or static storage) as the new stack when
resuming execution. Then all further processing (including resetting the guard
page and calling the user's stack-overflow-handler) is no longer up against the
stack overflow issue, and the user's handler can still call siglongjmp to
unwind back to a place earlier in the original stack.
char *address = (char *) ExceptionInfo->ExceptionRecord-
>ExceptionInformation[1];
/* Restart the program, giving it a sane value for %esp.
At the same time, copy the contents of
ExceptionInfo->ContextRecord (which, on Windows XP, happens
to be allocated in the guard page, where it will be
inaccessible as soon as we restore the PAGE_GUARD bit!) to
this new stack. */
unsigned long faulting_page_address = (unsigned long)address & -
0x1000;
unsigned long new_safe_esp = ((stk_extra_stack +
stk_extra_stack_size) & -16);
CONTEXT *orig_context = ExceptionInfo->ContextRecord;
CONTEXT *safe_context = (CONTEXT *) (new_safe_esp -= sizeof
(CONTEXT)); /* make room */
memcpy (safe_context, orig_context, sizeof (CONTEXT));
new_safe_esp -= 8; /* make room for arguments */
new_safe_esp &= -16; /* align */
new_safe_esp -= 4; /* make room for (unused) return address slot
*/
ExceptionInfo->ContextRecord->Esp = new_safe_esp;
/* Call stack_overflow_handler
(faulting_page_address,safe_context). */
ExceptionInfo->ContextRecord->Eip = (unsigned long)
&stack_overflow_handler;
*(unsigned long *)(new_safe_esp + 4) = faulting_page_address;
*(unsigned long *)(new_safe_esp + 8) = (unsigned long)
safe_context;
return EXCEPTION_CONTINUE_EXECUTION;
Another way of looking at this is that libsigsegv implemented its own version
of sigaltstack; the ideas used here in libsigsegv seem like they could be
ported to cygwin's exceptions.cc without too much trouble.
>
> I really don't like the games this package plays. I'm halfway tempted
> to just make it nonfunctional in Cygwin.
It works just fine, especially now that it only uses SEH for stack overflow
detection instead of assuming that all SEH faults imply SIGSEGV. I've hammered
it pretty hard as part of using it in m4. And if cygwin ever implements
sigaltstack, then just rerunning libsigsegv's configure script will pick that
up, and use sigaltstack rather than SEH for stack overflow management.
--
Eric Blake
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
