----Original Message----
>From: Jason FU
>Sent: 12 August 2005 08:35
> Bitmead, Chris <Chris.Bitmead> 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.
No, it doesn't 'work fine' under Linux. In fact it doesn't work at all,
on any platform. What you've written there is completely invalid and could
never work. Where on earth do you think main is going to return to after
you've discarded the old stack like that? The stack is for the compiler's
use, keep your hands off of it!
>> 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.
That would be a false inference unless you're using a version of the
cygwin dll with debugging information built in; if you aren't, that's just
the nearest exported symbol to the crash site but there could be several
functions in between.
>> Q1. Does cygwin and gcc have a real stack based alloca, or is it a fake
>> simulation?
Real.
>> Intuitively I assume that this kind of error would be caused
>> by the latter.
That just goes to show why 'intuition' is not a valid software development
methodology. http://catb.org/~esr/jargon/html/C/cargo-cult-programming.html
>> Q2. Why does this problem occur?
You just threw away the stack and jumped into space. What did you expect
to happen?
>> My vague guess
Again, let me urge you to reconsider your development methodology here.
Why make "vague guesses", when there is a simple and plain fact of the
matter that you could easily determine by either debugging your application
or reading the source code?
>>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.
No, it's completely wrong-headed, insane and unreasonable. Your code is
100% bogus and should be taken out the back, lined up against a wall, and
machine-gunned.
Then the bleeding corpse should be hung, drawn and quartered.
Then burnt.
Then the smouldering rubble should be jumped up and down on.
By a hippo.
>> Q4. Is there any work around?
Write better code. Legal, valid, ANSI-compliant C would be good.
>> 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).
Fortunately, there is absolutely nothing wrong with Cygwin's alloca; the
fault is entirely in the approach you have adopted for your implementation.
> Do you mean the following:
> [EMAIL PROTECTED] C++]$ make stack
> cc stack.c -o stack
> [EMAIL PROTECTED] C++]$ ./stack
> Segmentation fault
> I just can see that your code crashes there in both cygwin and linux.
I'm guessing that he tested it on a version of linux where the stdout
buffer got flushed before the crash happened, so he saw "hello" on the
output, saw the segv warning and pretended it didn't happen, and came to the
conclusion that his program 'works'.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
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/
