BIG Memory Problems....

Slickire · Mar 28, 2003

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 · Mar 29, 2003

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 · Mar 31, 2003

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 · Mar 31, 2003

An extract from one of my FAQs:

This is Pascal's memory model:

Code:

 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 · Apr 9, 2003

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 · Apr 10, 2003

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 · Apr 10, 2003

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 · Apr 12, 2003

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.

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

BIG Memory Problems....

Slickire

Technical User

LorenPechtel

Programmer

lionelhill

Technical User

Bertv100

Programmer

LorenPechtel

Programmer

Bertv100

Programmer

lionelhill

Technical User

LorenPechtel

Programmer

Similar threads

Part and Inventory Search

Sponsor