Contact US

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!

*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

BIG Memory Problems....

BIG Memory Problems....

BIG Memory Problems....

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.

Bert Vingerhoets
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?

Bert Vingerhoets
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