This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7] Updated: libsigsegv-2.6-1

On Thu, Jul 23, 2009 at 04:35:12PM +0000, Eric Blake wrote:
>> 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.
>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.

I see that the code tries to limit stack space usage before resetting
the stack but there really aren't any guarantees about how much you can
get away with.  But, if you are going to rely on the fact that the guard
page is available for the SEH then you can also rely on the fact that it
is available during a normal SIGSEGV operation.  In fact, the exception
stack is unwound when the signal handler is called so you should have
even more than what is available in the handler.  I don't see the need
for a special windows-based handler for cygwin in that case.

>              char *address = (char *) ExceptionInfo->ExceptionRecord-
>              /* 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 & -
>              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)
>              *(unsigned long *)(new_safe_esp + 4) = faulting_page_address;
>              *(unsigned long *)(new_safe_esp + 8) = (unsigned long) 
>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 without too much trouble.

Using this in would only catch the small subset of signals
handled by

>>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

The point is that this is using an undocumented "interface" into Cygwin.
If we decide to change anything in SEH handler, which we do from time to
time, this code is likely to break.  We are not likely to keep
libsigsegv in mind if we make future changes to the exception handler.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]