Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <602EF4562299D711978800065BEECE9A0D2D30D4@cbrml50.ag.gov.au> From: "Bitmead, Chris" To: "'cygwin AT cygwin DOT com'" Subject: Re: Cygwin.dll crash, alloca and custom stack Date: Mon, 15 Aug 2005 12:58:10 +1000 MIME-Version: 1.0 Content-Type: text/plain >Your demonstration code didn't use any Windows system calls. You were >calling cygwin functions. And printf doesn't use a Windows system call to write its output?? I fully admit to being in the dark about whether it is Windows or cygwin that is being annoying here. >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. A valid observation. I may need to push the fp onto the new stack and pop it off before restoring. >It is really not nonsensible for an OS to assume that it has control of >the stack. Lots of claims flying around, but no justification. An OS specified stack can provide automatic extension to applications that are interested in that feature, but apart from that I don't see why it should give a rip what an app does with its stack. >I already did earlier. Let's not loop. You said that Windows has the TIB area. Ok, but if I restore the system stack before talking to windows, I don't see any problem. >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? Well you've heard of sigaltstack() right? That's an API where you call malloc() to create some stack space. But I guess that API is "bad" because it means that the OS is no longer "controlling" where the stack is right? >And, I assume that there will be no recursion in your program? Because if there >is you're guaranteed heap corruption. No, each function call has its own scheme environment and therefore its own stack. So on a recursive call a new environment is allocated and thus a new stack is allocated. Of course, most scheme recursion is tail calls and that will be implemented with longjmp, thus re-using the same stack. By allocating my own stacks I can longjmp down the stack (conceptually), which is normally a no-no, but I've shown to work fine if you allocate your own chain of stacks that are not garbage collected till they have no references. ----------------------------------------------------------------- If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- 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/