Visual C++: stack overflow

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?!

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).

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

Look at the documentation for your compiler. You should be able to increase the size of the stack.

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

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

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

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.

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

quote:

---

Original post by Paradigm Shifter
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).

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.

quote:

---

Original post by Thrump
[quote]Original post by Paradigm Shifter
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 reply...
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]

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]