X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 23 Jul 2009 13:16:56 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] Updated: libsigsegv-2.6-1
Message-ID: <20090723171656.GA6973@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4A678AC7 DOT 7090303 AT x-ray DOT at>  <4A6854F8 DOT 4060204 AT byu DOT net>  <20090723144038 DOT GA11519 AT ednor DOT casa DOT cgf DOT cx>  <loom DOT 20090723T145926-237 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090723T145926-237@post.gmane.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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

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

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

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.

cgf

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