Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sun, 14 Aug 2005 21:46:43 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin.dll crash, alloca and custom stack
Message-ID: <20050815014642.GA17388@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <602EF4562299D711978800065BEECE9A0D2D30D3 AT cbrml50 DOT ag DOT gov DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <602EF4562299D711978800065BEECE9A0D2D30D3@cbrml50.ag.gov.au>
User-Agent: Mutt/1.5.8i

On Mon, Aug 15, 2005 at 11:11:47AM +1000, Bitmead, Chris wrote:
>>I suggest you investigate those alternatives instead of trying to
>>do something that cannot work, and then getting all pissy when people try to
>>dissuade you from wasting your time. 
>
>That's strange. Now that I know that on Windows it likes to use its own
>stack for system calls, its working fine by just restoring the system stack
>temporarily.

Your demonstration code didn't use any Windows system calls.  You were
calling cygwin functions.  I notice that you save your stack pointer in
an automatic variable (saved on the stack), reset the stack pointer, and
then get it back again.  You are relying on the fact that the frame
pointer doesn't change in that scenario.  That still seems sort of
fragile to me.  I can imagine that some gcc optimization will come along
(if it hasn't already) which defaults to using -fomit-frame-pointer for
some optimization and then your code will break.

>I do remain curious why Windows actually cares whereas Linux acts
>sensibly and doesn't carebut it matters little for my purposes.

It is really not nonsensible for an OS to assume that it has control of
the stack.

>>Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com> wrote:
>>What you are trying to do is a bad idea.  
>
>Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? 

I already did earlier.  Let's not loop.

>>Btw, have you thought about how to handle stack overflow?  What happens
>>when the program pushes its way to the top of your malloced region?
>
>Each Scheme function call has its own environment that is chained to
>previous environments.  Each environment has its own stack.  The C code
>that executes a scheme function uses a small and well-defined amount of
>stack.  Restoring the system stack for external library calls is going
>to be a good idea anyway, because they can use arbitrary amounts of
>stack.  But for the interpreter itself the exact amount of stack
>required for one lambda can be calculated by trial and error.  The
>other way to implement it is to copy the entire stack when switching
>co-routines, but I'm trying to avoid that.

And what happens when the compiler decides to allocate more memory on
the stack than what seems possible from code inspection, like when
there's a signal?  That can consume quite a bit of stack space.  And, I
assume that there will be no recursion in your program?  Because if there
is you're guaranteed heap corruption.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/