• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# Visual C++: stack overflow

## Recommended Posts

Structural    328
I have no idea where this runtime error is coming from. I can''t see anything I''ve done wrong:
terrain.loadTerrain("terrain.raw");

{
unsigned char terra[TERRAINSIZE*TERRAINSIZE];
FILE *pFile = NULL;
etc

As soon as it calls this function it gives an error, it doesn''t even enter the function. When I call another function of the same object (a few thousand times each frame), it goes fine. What am I missing? I must be something obvious.

##### Share on other sites
Structural    328
oh..... great....

I have managed to narrow the problem down to one line:
unsigned char terra[TERRAINSIZE*TERRAINSIZE];

It appears that I cannot declare a char aray of one MB (1024 * 1024)........ heh...... nasty
1024 * 1012 doesn''t give a problem but anything higher gives an error.
Is there something I''m missing? Is there a limit of how much memory you can declare?!

##### Share on other sites
ludemann8    122
You are overflowing the stack. The stack is only of limited size, and a variable of that size is far beyond what the stack can handle.

Store the terrain buffer on the heap (using new/malloc).

##### Share on other sites
MichaelT    214
using:

unsigned char whatever[1024*1024];

works just fine but you need to place it globally and not inside the function.

____________________________________________________________
Try RealityRift at www.planetrift.com

##### Share on other sites
petewood    819
Look at the documentation for your compiler. You should be able to increase the size of the stack.

##### Share on other sites
Structural    328
Thanks!
I got around it by making the array part of the class.

Still, I didn''t know this. I always assumed that any array, whereever I declared it, was put in memory, not on the stack.
Is this something particular to microsoft visual, or is this something that every compiler does?
A more technical question: WHY is it put on the stack? Why not in memory? Is this a speed issue?

TY

##### Share on other sites
MichaelT    214
quote:
Original post by Structural
Thanks!
I got around it by making the array part of the class.

Still, I didn''t know this. I always assumed that any array, whereever I declared it, was put in memory, not on the stack.
Is this something particular to microsoft visual, or is this something that every compiler does?
A more technical question: WHY is it put on the stack? Why not in memory? Is this a speed issue?

TY

The compiler optimizes the variables inside a function to be more efficient and that generally means stack and registers since they are most effective (performance) and as long as it is possible to do so. One could argue that there should be a "memory" just as there is a "register".

____________________________________________________________
Try RealityRift at www.planetrift.com

##### Share on other sites
chollida1    532
Your array sits on the stack,not the heap, its probably being destroyed while you''re trying to read it. That''s why you get your exeption.

Cheers
Chris

##### Share on other sites
Thrump    169
Some languages that don''t support recursion have only 1 static copy of all local variables. That''s all that is needed in this case. A stack supports recursion efficiently, and saves a little space.

##### Share on other sites
You do only have 1 copy of static locals, and C does support recursion. That''s why it''s dodgy to save stack space by changing locals to static locals, since if you call the function recursively you wont get a new copy. static locals also disallow re-entrancy for multithreaded functions unless you use a critical section or something similar.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

##### Share on other sites
Thrump    169
quote:
You do only have 1 copy of static locals, and C does support recursion.

I said 1 static copy, not 1 copy of a static. I may not have explained it very well, but if you understand there''s a big difference. In many languages that don''t support recursion (like old Fortran, not sure about more recent Fortrans) all local variables are static. As far as I can tell, there''s not really any other major reason to have a stack for local data other than recursion. Speed is not an issue here, as statics are just as fast as a stack. However, a stack is the most efficient storage when recursion is needed (that I can think of, my knowledge here is not bullet-proof).

##### Share on other sites
daerid    354
ALL data, unless specifically allocated by new/malloc, is allocated on the stack (unless it''s global).

Most of the time, the pointers you use to access heap memory are allocated on the stack.

##### Share on other sites
quote:
Original post by Thrump
You do only have 1 copy of static locals, and C does support recursion.

Thrump said...
I said 1 static copy, not 1 copy of a static. I may not have explained it very well, but if you understand there's a big difference. In many languages that don't support recursion (like old Fortran, not sure about more recent Fortrans) all local variables are static. As far as I can tell, there's not really any other major reason to have a stack for local data other than recursion. Speed is not an issue here, as statics are just as fast as a stack. However, a stack is the most efficient storage when recursion is needed (that I can think of, my knowledge here is not bullet-proof).

I misread your meaning, sorry. Isn't it daft to make all locals static in a language not supporting recursion though, you'd need to pre-allocate storage for all locals in all functions before the program would run?

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

[edited by - Paradigm Shifter on January 29, 2003 6:15:38 AM]

##### Share on other sites
MichaelT    214
quote:
Original post by daerid
ALL data, unless specifically allocated by new/malloc, is allocated on the stack (unless it's global).

Most of the time, the pointers you use to access heap memory are allocated on the stack.

I would advice to use windows own memory managers over new/malloc since windows memory managers can guarantee contigous memory where new/malloc cannot. For those who don't know what this means, it means that there is a performance penalty when using non contigous memory. Memory fragmentation is a real issue just as fragmented harddrives are. I cannot speak for other OS but I would assume that there are similar opportunities for optimization.

____________________________________________________________
Try RealityRift at www.planetrift.com
Feel free to comment, object, laugh at or agree to this. I won't engage in flaming because of what I have said. I could be wrong or right but the ideas are mine.

[edited by - MichaelT on January 31, 2003 1:35:59 AM]