BIG Memory Problems....

[Slickire]

Helo,
im writing a simple raycasting engine, ive set up some memory in the program for a virtual screen which i flip to vga. it is all working fine, but after about a minute the program stops with error 200: stack overflow, i cant see why it would do this, as i am reusing most variable and reusing the memory for the screen by looping the program.
any ideas or solutions anyone?
thanks - DF

 

[LorenPechtel]

Stack overflow isn't due to memory leaks, it's due to getting too deep. There's two likely cases:

Too many local variables in a recursive routine.

Recursion run wild.

A less likely but still possible cause is large local variables.

 

[lionelhill]

The default stack in Turbo Pascal 6.0 is 16K, and you can't increase the stack beyond 64K if you're in a dos-style environment. That means that creating large arrays as local variables or parameters is not good if you have a recursive routine: even 1K of array (not hard to do) limits you to 16 levels of recursion, assuming no one else wants any stack space at all.
But I personally have a bias against recursion anyway.

LorenPechtel: as a matter of interest if you have time to answer, is there an outside tiny possibility that having a huge heap increases the chance of a stack overflow, because I have vague memories that the stack grows downwards into the same memory as the heap uses (upwards), so they can collide in the middle? If so, how does the run-time stuff decide who caused the error?? This hasn't happened to me, but I was just wondering....

 

[Bertv100]

An extract from one of my FAQs:

This is Pascal's memory model:

 HeapEnd   --------------------------------------
           |                                    |
           |               Heap                 |
           |                                    |
 HeapOrg   --------------------------------------
           |           Overlay buffer           |
 SSeg      --------------------------------------
           |               Stack                |
 SPtr      --------------------------------------
           | Data segment with global variables |
           |====================================|
           |           Typed constants          |
 DSeg      --------------------------------------
           |Code segment of the run-time library|
           |------------------------------------|
           |         Code segment unit A        |
           |------------------------------------|
           |       Other unit code segments     |
           |------------------------------------|
           |         Code segment unit E        |
           |------------------------------------|
           |      Code segment main program     |
 CSeg      ======================================
           |     Program Segment Prefix (PSP)   |
 PrefixSeg --------------------------------------

As for large local variables, store them in heap memory in stead of in stack memory. Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com

http://student.vub.ac.be/~bvingerh/

Don't worry what people think about you. They're too busy wondering what you think about them.

 

[LorenPechtel]

The stack/heap collision you refer to can only happen with a smaller memory model than used by TP. TP's stack is fixed and not shared with the heap.

 

[Bertv100]

If stack checking is turned off (with the {$S-} compiler directive), it is possible that it grows into a part of memory where it shouldn't be. But who turns off stack checking anyway? Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com

http://student.vub.ac.be/~bvingerh/

Don't worry what people think about you. They're too busy wondering what you think about them.

 

[lionelhill]

Me! But only in final versions of programmes, and only parts where speed matters. The trouble with stack checking is that it inserts a far call to the stack checking code at the start of every single procedure (well, at least in Turbo 6.0 that's what it does). If you're writing a recursive procedure for evaluating something, that can be a lot of extra overhead... And there's an argument that there's not a lot of point in carefully keeping a frequently-called procedure in the same unit as its caller, and making it near-called, if it promptly performs an unnecessary far call.
But maybe this changed in other versions of pascal.

 

[LorenPechtel]

Note that you can overflow the stack *WITHOUT* triggering the waring! It can only happen if you have a lot of local variables. The allocate-stack-frame routine does *NOT* check for wraparound.