Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
To: cygwin AT cygwin DOT com
From: Jason FU <tsfu AT hkucs DOT org>
Subject:  Re: Cygwin.dll crash, alloca and custom stack
Date: Fri, 12 Aug 2005 07:35:06 +0000 (UTC)
Lines: 89
Message-ID:  <loom.20050812T093211-562@post.gmane.org>
References:  <602EF4562299D711978800065BEECE9A0D2D30CD AT cbrml50 DOT ag DOT gov DOT au>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes

Bitmead, Chris <Chris.Bitmead <at> ag.gov.au> writes:

> 
> 
> I'm writing an implemention of a scheme interpreter in C, and as people
> familiar with that language know, it requires some stack manipulation. Now
> to test this out I wrote a little program....
> 
> #include <stdio.h>
> 
> int main() {
> 	char * st1;
> 	st1 = (void *)malloc(5000) + 5000;
> 	asm("mov %0, %%esp" : : "r" (st1)); 
> 	fprintf(stderr, "hello\n");
> }
> 
> This program crashes silently and prints nothing under cygwin. However this
> kind of thing works fine under Linux.
> 
> Now if I run it under gdb it says 0x610dfbb3 in cygwin1!_alloca () from
> /usr/bin/cygwin1.dll
> 
> Which seems to indicate that the problem has something to do with alloca.
> 
> Q1. Does cygwin and gcc have a real stack based alloca, or is it a fake
> simulation? Intuitively I assume that this kind of error would be caused by
> the latter.
> 
> Q2. Why does this problem occur? My vague guess is that something in the
> bootstrap code for cygwin calls alloca, and because of the memory layout of
> stack and heap, creating a heap based stack makes it free it prematurely.
> 
> Q3. Shouldn't this be fixed in cygwin? While this is an unusual case, it
> seems reasonable to me that a program should be able to create a new stack
> if it wants to.
> 
> Q4. Is there any work around? I'm guessing that if cygwin uses a fake
> alloca, then a better implementation would fix it, but is there any way to
> substitute another one without actually rebuilding cygwin.dll (which I am
> loath to do).
> 
> -----------------------------------------------------------------
> 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. 
> 
> 



Do you mean the following:

=====================================================================
[ito2 AT intra C++]$ cat stack.c
#include <stdio.h>

int main() 
{
  char * st1;
  st1 = (void *)malloc(5000) + 5000;
  asm("mov %0, %%esp" : : "r" (st1)); 
  fprintf(stderr, "hello\n");
}
[ito2 AT intra C++]$ rm stack
[ito2 AT intra C++]$ cat stack.c
#include <stdio.h>

int main() 
{
  char * st1;
  st1 = (void *)malloc(5000) + 5000;
  asm("mov %0, %%esp" : : "r" (st1)); 
  fprintf(stderr, "hello\n");
}
[ito2 AT intra C++]$ make stack
cc     stack.c   -o stack
[ito2 AT intra C++]$ ./stack 
Segmentation fault

=====================================================================

I just can see that your code crashes there in both cygwin and linux.


Jason



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