Stack Overflow error

Jun 24, 2010 at 4:36pm
I am using the Bloodshed Dev-C++ compiler and am getting a stack overflow error.

Does anyone know which compile /link flags i need to use in project options to increase the stack size?

Thanks

Jefe
Jun 24, 2010 at 5:06pm
First check if you have infinite recursion. That's the one of the most common causes of stack overflow.
Also check if you're declaring a stack array that doesn't fit in the stack. If you are, move it to dynamic allocation.
Jun 24, 2010 at 9:58pm
It is stalling on an array declaration eg array[30][2000]

ie a trivial size;

I do need to get arrays much larger than this ...

NB I did try to run this on an old MSVC-V6 compiler ... and the default stack size there was a miserly 1MB. Soon resolved by increasing the stack size via setting a /STACK linker option

but I dont know the settings for the Bloodshed Dev-C++ compiler ( based on Unix MinGw i think ? )

Any help appreciated

Thanks

Jefe
Jun 24, 2010 at 10:03pm
240K isn't really trivial. Suggest allocating on the heap.
Jun 24, 2010 at 11:07pm


The purpose of the program is to compare execution times of heap and stack;
ie i allocate same size arrays on each and compare execution times, so i will be allocating a same size array on the heap as you suggest, but ... I still need to increase the stack size ..

With 3GB of memory an array of 240K looks small, surely

So i want to increase the stack size ... is there a /STACK linker option for this compiler?

Any help appreciated.
Jun 24, 2010 at 11:49pm
You can use -Wl,--stack=[size in bytes here].
Still, the default size is 2M, which is plenty enough for even large applications.
Allocating on the stack is much faster than on the heap, but accessing the memory is the same.
Jun 25, 2010 at 3:43am
The stack and heap are for entirely different purposes, so that's not a really useful comparison. That's precisely why the stack is so much smaller than the heap. It's not meant for allocating ridiculously-sized arrays. 1 MiB of stack space is more than necessary for most applications.
Jun 25, 2010 at 10:16am
What exactly do you plan to do. You should get no execution time difference form heap and stack if you ignore the time "new" takes. Counting the time "new" takes makes the comparison somewhat unrealistical since on the heap the allocation is done on program start.
Jun 25, 2010 at 12:25pm
on the heap the allocation is done on program start
No, it isn't. Maybe you're thinking of static storage.
Jun 25, 2010 at 1:41pm
The real difference comes in dynamic allocation vs. not. Consider:

1
2
3
4
5
6
7
8
int stack_array[ 10 ][ 10 ];

// vs.

int** dynamic_array;
dynamic_array = new int*[ 10 ];   // Allocating 40 bytes here
for( size_t i = 0; i < 10; ++i )
    dynamic_array[ i ] = new int[ 10 ];  // Allocating 40 bytes here, 10 times = 400 bytes 


In case 1, exactly 400 bytes of memory is needed (assume 32 bit here, please) for the array.
In case 2, the total size of allocation is 400 + 40 = 440.

The difference? Pointers.

To access element [3][4] of stack_array, the compiler essentially has to generate the following
pseudo-assembler:

1
2
3
4
5
6
LD  r1, stack_array       // r1 <- address-of stack_array
LD  r2, 10                    // r2 <- 10
MUL r2, 3                    // r2 *= 3
ADD r2, 4                    // r2 += 4
ADD r2, r1                  // r2 += r1
LD r3, [r2]                  // r3 <- value stored at that memory location 


Note: 2 memory accesses.

To access element [3][4] of dynamic_array, here's what it needs to do:

1
2
3
4
5
LD r1, dynamic_array         // r1 <- address-of dynamic_array
ADD r1, 3                          // r1 += 3
LD r2, [r1]                         // r2 <- value stored at that memory location
ADD r2, 4                          // r2 += 4
LD r3, [r2]                        // r3 <- value stored at that memory location 


Note: 3 memory accesses. The extra memory access makes accessing dynamically
allocated multi-dimensional arrays slower than if they were fixed length and on the
stack. (Even though it might look faster because it is fewer instructions, the memory
accesses dominate the execution time).
Jun 25, 2010 at 2:08pm
Well, that's not really the same. [][] is syntactical sugar for accessing a one-dimensional array.
Also, you forgot to first load the pointer and then dereference the pointer.
1
2
3
4
LD    r1, dynamic_array  //load pointer
//ADD r1, 3              //this line would make sense if dynamic_array was an array of pointers
LD    r2, [r1]           //NOW we have the address of the actual array
...
so in fact it should take 4 memory accesses to access an element in that dynamic array.
Last edited on Jun 25, 2010 at 2:08pm
Topic archived. No new replies allowed.