0

On my machine, the following code apparently produces stacksmashing:

#include <stdio.h>
#include <stdlib.h>

void function2(int* data);
void function1();

void function2(int* data)
{
    printf("grps ");
    printf(" ");
    printf(" one more line\n");
}

void function1()
{
    printf("function1_checkpoint1\n");
    int *tempData[520721];
    function2(tempData);
}

int main()
{
    printf("main_checkpoint1\n");
    function1();
    printf("main_checkpoint2\n");
    return 0;
}

If it does not crash on your machine, try replacing 520721 by some more crazy number like 10 million. The output I have is:

main_checkpoint1

And then crash. If I replace 520721 by 520720 I get:

main_checkpoint1
function1_checkpoint1

And then also crash. If instead I replace printf(" ") by printf("") (suppress the space, printing an empty string), the program is running normally and I get

main_checkpoint1
function1_checkpoint1
grps  one more line
main_checkpoint2

Finally, replacing int *tempData[520721]; by int *tempData=malloc(520721*sizeof(int)); with subsequent testing of the success of malloc() and usage of free(tempData); have always worked in all the cases I tested.

As you can see, all I am doing is calling a first function in main, which creates a very big local int table, and then passing the pointer to this int table, to a second function. And the second function does nothing except printfs and doesn't even touch to the pointer or the data it points to.

I was just wondering what on earth was going on in my machine...why is this code producing a crash?

Thanks very much for your insight!

MrBrody
  • 301
  • 2
  • 13

1 Answers1

2

It's crashing because you're causing a stack overflow. That huge array is allocated on the stack, and the stack isn't that big.

Simply allocating a variable is enough to make it move the stack pointer. You don't write to it, but when you then call your other function, your program tries to write to the stack, past the huge array, to allocate the next stack frame. This is when it crashes.

You've already got the solution: use a dynamic allocation instead.

zneak
  • 134,922
  • 42
  • 253
  • 328
  • Yes but why...I am not writing anything to the int table! – MrBrody Sep 07 '13 at 00:48
  • The simple fact that it exists still moves the stack pointer. – zneak Sep 07 '13 at 00:48
  • this means that even when the size of the array is known in advance and fixed, you still have limitations to respect? – MrBrody Sep 07 '13 at 00:49
  • 1
    Yes. You still have a stack size to respect. On Windows the default stack size is 1MB. Stack overflowing is the result of smashing that limit, because you're nesting too many calls, or because you're trying to use too much stack space, or a combination of both. For sizeable allocations, you need to use dynamic allocations. – zneak Sep 07 '13 at 00:51
  • I did not know that. I thought that upon compilation of a static executable, the size needed in memory would be signaled to the OS somehow..I did not know this 1MB limit on Windows, I thought stack smashing only occurred when one function was writing outside of some array on purpose. You taught me something! Thanks! – MrBrody Sep 07 '13 at 00:53