Board index » delphi » stack overflow error

stack overflow error

I've written a Pascal program for my study of programming languages
course.  The purpose of the program is to generate an arrays of 10, 100,
1000, and 10000 integers, then sort the arrays using the CombSort,
Bubble Sort, and Quick Sort, counting and printing out the number of
comparisons needed for each sort at each array level.  The program
appears to be working fine until I get to the 10,000 array - then it
gives me the final messages, but it craters with a stack overflow
error.  So, I really don't have any idea if my final counts are correct
or not.

I've tried running the program on TP 7, the 1.5 version for Windows 3.1,
and a freeware version of Pascal.  I've tried running it on a Pentium
133 with 16mb of RAM, and a Pentium II 266 with 64mb of RAM.  I've tried
increasing the stack size up to 16384.

Is there something else I can do?  I'm *not* a Pascal programmer - in
fact, after this class, I doubt I ever look at Pascal again.

 

Re:stack overflow error


Quote
Dana Holland wrote:

> I've written a Pascal program for my study of programming languages
> course.  The purpose of the program is to generate an arrays of 10, 100,
> 1000, and 10000 integers, then sort the arrays using the CombSort,
> Bubble Sort, and Quick Sort, counting and printing out the number of
> comparisons needed for each sort at each array level.  The program
> appears to be working fine until I get to the 10,000 array - then it
> gives me the final messages, but it craters with a stack overflow
> error.  So, I really don't have any idea if my final counts are correct
> or not.

The reason may be that the programs you use, especially the quick sort,
use recursion. And a recursive call takes up much memory, especially if
either a parameter, which is not a var parameter, or a local variable is
an array. Because your assignment is part of a course in programming
languages, this may be precisely the point it should teach you. So, take
a closer look at the way your programs use memory. This may be useful
when you use other languages as well.

--
Rommert J. Casimir
Tilburg University, Room B435, tel 31 13 4662016
P.O. Box 90153, 5000LE Tilburg, The Netherlands
http://cwis.kub.nl/~few/few/BIKA/rc_home.htm

Re:stack overflow error


Quote
Dana Holland wrote:
> I've written a Pascal program for my study of programming languages
> course.  The purpose of the program is to generate an arrays of 10, 100,
> 1000, and 10000 integers, then sort the arrays using the CombSort,
> Bubble Sort, and Quick Sort, counting and printing out the number of
> comparisons needed for each sort at each array level.  The program
> appears to be working fine until I get to the 10,000 array - then it
> gives me the final messages, but it craters with a stack overflow
> error.  So, I really don't have any idea if my final counts are correct
> or not.

> I've tried running the program on TP 7, the 1.5 version for Windows 3.1,
> and a freeware version of Pascal.  I've tried running it on a Pentium
> 133 with 16mb of RAM, and a Pentium II 266 with 64mb of RAM.  I've tried
> increasing the stack size up to 16384.

The problem may be that your sortroutines use recursion. First try to
increase the Stack up to 65520. If this will not solve your problem and you
are shure that more stack will solve it, than I offer you this suggestion:

First analyse which procedure(s) or function(s) are used within the
recursion and be sure that the procs recurses 2 times or more. If you got a
stack overflow at first step, than you have to many local-variables. In this
case nobody can help you, because the limitation of one stackcall
is 65520.

Otherwise go one my homepage http://home.t-online.de/home/andreas.killer and
try to download the file HEAPS100.ZIP. These file has a unit in it that
allows you to increase the stack to all avaible memory that is given to your
program, i.E. up to 64Mb if you compile it with BP7 in DPMI-Mode.

Than you have to modify your recursion-routines like this:

 procedure ThatIsUsedInYourRecursion;
 label
   ExitPoint;
 begin
   {-Startstack checks the stack and switch to a new stack if necessary}
   if not StartStack then
     {-If your program reach this point all avaible memory was allocated}
     RunError(1202);

   {-Here can you places any type of code you want, but not EXIT! Use GOTO
EXITPOINT instead!}

ExitPoint:
   {-Endstack checks the stack and switch to an older stack if necessary}
  EndStack;
 end;

Compile and start your program. If you got a RTE 1202 from the line above
and in your program is more than 400Kb heap avaible, I'm sure
you have a bug in your program, because nobody needs so many stack. :)

If you got a RTE 202 than you have not found all procedures that are used in
your recursion.

Hope it helps, by Andreas.

Re:stack overflow error


In article <6tvm9f$s0...@news02.btx.dtag.de>,

Quote
Andreas Killer <Andreas.Kil...@t-online.de> wrote:

>The problem may be that your sortroutines use recursion. First try to
>increase the Stack up to 65520. If this will not solve your problem and you
>are shure that more stack will solve it, than I offer you this suggestion:

No, the first thing one should do is to analyze where the problem is and
only after that increase the stack.

The most likely cause is that the arrays themselves are local.

Quote

>First analyse which procedure(s) or function(s) are used within the
>recursion and be sure that the procs recurses 2 times or more. If you got a
>stack overflow at first step, than you have to many local-variables. In this
>case nobody can help you, because the limitation of one stackcall
>is 65520.

Osmo

Re:stack overflow error


Thanks for all the suggestions with my stack overflow problem.  Everyone in
the class was experiencing the same problem; the professor said last night
that he didn't intend for us to have such a complicated problem, so he
lowered the size of the array.  However, you've given me some good
information for future problems.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re:stack overflow error


In article <6u8kcm$...@kruuna.Helsinki.FI>, Osmo Ronkanen
<ronka...@cc.helsinki.fi> writes

Quote
>No, the first thing one should do is to analyze where the problem is and
>only after that increase the stack.

Agreed.

However these days is there any inherent problem per se with a max
stack?

Quote
>The most likely cause is that the arrays themselves are local.

Agreed. However they are at least temporary on the stack.

--
Oz

Re:stack overflow error


In article <6xCrRHAyHAC2E...@upthorpe.demon.co.uk>,

Quote
Oz  <O...@upthorpe.demon.co.uk> wrote:
>In article <6u8kcm$...@kruuna.Helsinki.FI>, Osmo Ronkanen
><ronka...@cc.helsinki.fi> writes

>>No, the first thing one should do is to analyze where the problem is and
>>only after that increase the stack.

>Agreed.

>However these days is there any inherent problem per se with a max
>stack?

Increasing the stack without knowing the problem is killing the
messenger.

Quote

>>The most likely cause is that the arrays themselves are local.

>Agreed. However they are at least temporary on the stack.

I do not see why anyone would put the arrays even temporarily on the
stack.

Osmo

Re:stack overflow error


In article <6u9jt7$...@kruuna.Helsinki.FI>, Osmo Ronkanen
<ronka...@cc.helsinki.fi> writes

Quote
>>Agreed. However they are at least temporary on the stack.

>I do not see why anyone would put the arrays even temporarily on the
>stack.

Because they are temporary and local to that routine?
So they do not remove resources from the valuable data segment?
So one doesn't have to worry about accidentally x-referencing global
variables?

Mind you I've only just started to use pascal after a gap of several
years, so I'm pretty rusty to say the least.

--
Oz

Re:stack overflow error


JRS:  In article <6u9jt7$...@kruuna.Helsinki.FI> of Wed, 23 Sep 1998
04:46:15 in comp.lang.pascal.borland, Osmo Ronkanen

Quote
<ronka...@cc.helsinki.fi> wrote:
>In article <6xCrRHAyHAC2E...@upthorpe.demon.co.uk>,
>Oz  <O...@upthorpe.demon.co.uk> wrote:
>>In article <6u8kcm$...@kruuna.Helsinki.FI>, Osmo Ronkanen
>><ronka...@cc.helsinki.fi> writes

>>>No, the first thing one should do is to analyze where the problem is and
>>>only after that increase the stack.

>>Agreed.

>>However these days is there any inherent problem per se with a max
>>stack?

>Increasing the stack without knowing the problem is killing the
>messenger.

And if the message then stops, you know you've killed the right one.

If small data works and large data overflows, and a stack maximise
prevents overflow, then one has very likely indeed dealt with the
problem sufficiently for the specific purpose.  Though if it were
commercial code, stack overflow should be rendered impossible, if
necessary by "Abandon Hope, the Stack is Brim-full" code.

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web <URL: http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
  PAS, EXE in <URL: http://www.merlyn.demon.co.uk/programs/> - see 00index.txt.
  Do not Mail News to me.    Before a reply, quote with ">" or "> " (SoRFC1036)

Re:stack overflow error


In article <hwwALWAV0OC2E...@merlyn.demon.co.uk>, Dr John Stockton
<j...@merlyn.demon.co.uk> writes

Quote
>>Someone or other said:
>>Increasing the stack without knowing the problem is killing the
>>messenger.

>And if the message then stops, you know you've killed the right one.

Whereupon, preumably, anyone here locates said problem and assesses it's
importance?

Quote
>If small data works and large data overflows, and a stack maximise
>prevents overflow, then one has very likely indeed dealt with the
>problem sufficiently for the specific purpose.  

Sounds dangerous 'for the specific purpose'. It suggests a non-specific
purpose might come and bite later ...

Quote
>Though if it were
>commercial code, stack overflow should be rendered impossible, if
>necessary by "Abandon Hope, the Stack is Brim-full" code.

Er, please y'r honor, what's the "Abandon hope, the stack is brimfull"
code? Do you typically leave stack checking on? I rather doubt it.

I am also interested to know if you have ever coded the above message
into anything. If so I am impressed, even more impressed if you ever got
a phonecall saying .....

--
Oz

Re:stack overflow error


In article <hwwALWAV0OC2E...@merlyn.demon.co.uk>,
Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

Quote
>JRS:  In article <6u9jt7$...@kruuna.Helsinki.FI> of Wed, 23 Sep 1998
>04:46:15 in comp.lang.pascal.borland, Osmo Ronkanen
><ronka...@cc.helsinki.fi> wrote:
...

>>Increasing the stack without knowing the problem is killing the
>>messenger.

>And if the message then stops, you know you've killed the right one.

If you prefer such trial and  error programming then that is your
business. I just hope I never have to use such programs. Especially
when dealing with recursion such a method might fix it for you but
with different data it might still crash.

Osmo

Re:stack overflow error


In article <GCHUNKAk4TC2E...@upthorpe.demon.co.uk>, Oz
<O...@upthorpe.demon.co.uk> writes
Quote
>In article <hwwALWAV0OC2E...@merlyn.demon.co.uk>, Dr John Stockton
><j...@merlyn.demon.co.uk> writes

>>Though if it were
>>commercial code, stack overflow should be rendered impossible, if
>>necessary by "Abandon Hope, the Stack is Brim-full" code.

>Er, please y'r honor, what's the "Abandon hope, the stack is brimfull"
>code? Do you typically leave stack checking on? I rather doubt it.

It is certainly easy to write code in alot of, if not most, situations
such that your code is *not* going to exceed the stack available.

Checking remaining stack availability yourself when there is the
possibility of a particular procedure exceeding it is not difficult to
do and allows you to terminate the whole or part of the program
gracefully with the option to save work. The program would terminate
abruptly with a stack error with $S+ or behave erratically, if at all,
after a stack error using $S-. Check out Sptr.

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.

Re:stack overflow error


In article <6ubgqg$...@kruuna.Helsinki.FI>, Osmo Ronkanen
<ronka...@cc.helsinki.fi> writes

Quote
>If you prefer such trial and  error programming then that is your
>business. I just hope I never have to use such programs. Especially
>when dealing with recursion such a method might fix it for you but
>with different data it might still crash.

I really cannot see any difference between enlarging a stack because you
chose to use a large local data structure or enlarging it to cover some
recursion. Indeed any significantly recursive routine has the capability
of blowing the stack even for small local variables and even with a
large stack so it seems to me that ANY recursive routine is more of a
risk per se than a large local data structure per se.

--
Oz

Re:stack overflow error


Quote
> >If you prefer such trial and  error programming then that is your
> >business. I just hope I never have to use such programs. Especially
> >when dealing with recursion such a method might fix it for you but
> >with different data it might still crash.

> I really cannot see any difference between enlarging a stack because you
> chose to use a large local data structure or enlarging it to cover some
> recursion. Indeed any significantly recursive routine has the capability
> of blowing the stack even for small local variables and even with a
> large stack so it seems to me that ANY recursive routine is more of a
> risk per se than a large local data structure per se.

   Yes, but there are things one should always do to _minimize_ that
risk: reduce the amount of local data in the routine to bare minimums;
pass pointers or small data types as parameters; use as much global data
as possible; etc.
   Simply enlarging the Stack parameter is seldom an effective solution
for Stack Overflow errors, since (as Osmo pointed out) it's an open
invitation to incur 202 aborts when the application is in production (and
is most costly to fix).  Instead, being aware of the issues involved with
Stack usage will guide the programmer to (1) be careful how recursion is
used, (2) control nesting through good implementation/design, (3) reserve
an optimal amount of Stack space (to maximize all system resources), and
(4) avoid implementation which _will_ cause data/volume-dependant
problems.  Knowing how to use the available resources is part of
effective and proper application design - and simply maximizing all
values is a "cop out" which will surely come back to haunt the
programmer...

Re:stack overflow error


In article <0UyheXACjWC2Y...@pedt.demon.co.uk>, Pedt Scragg
<newsmas...@pedt.demon.co.uk> writes

Quote
>It is certainly easy to write code in alot of, if not most, situations
>such that your code is *not* going to exceed the stack available.

Indeed so.

Quote

>Checking remaining stack availability

.....

Quote
> Check out Sptr.

Ooops. A case of first engauge brain before opening mouth ...

--
Oz

Go to page: [1] [2]

Other Threads