×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

BIG Memory Problems....

BIG Memory Problems....

BIG Memory Problems....

(OP)
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

RE: BIG Memory Problems....

      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.

RE: BIG Memory Problems....

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

RE: BIG Memory Problems....

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.

RE: BIG Memory Problems....

     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.

RE: BIG Memory Problems....

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.

RE: BIG Memory Problems....

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.

RE: BIG Memory Problems....

     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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close