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.

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

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.

     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.

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.

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.

     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.