Board index » delphi » Error 202: Stack overflow error.

Error 202: Stack overflow error.

Where should I start to debug my program? :)

I get the error when I have allocolated and "freed" memory quite many
times.

Something like this:

type     500_105_array : ^my_array;
            my_array : array[1..500] of string[105];
var
    test : 500_105_array;
if memavail>sizeof(my_array)+1000 then
    getmem(p,sizeof(my_array));
...
...
...
freemem(p,sizeof(my_array);

Can the program chrash if you access memory too often or too "quick"?
But, it's not a loop which allocades and dellocades the memory, it's me
( :) ) and that means it's not "too" quick or "too" many times before it
fails.

I free the memory each time.

Some thoughs about my problem would be appreciated!

/Tobias

Ps. Sorry all the quotes... :) My english is failing today... Ds.

 

Re:Error 202: Stack overflow error.


In article <369A1364.72309...@swipnet.se>, Tobias Andersson

Quote
<T...@swipnet.se> wrote:
> type     500_105_array : ^my_array;
>             my_array : array[1..500] of string[105];
> var
>     test : 500_105_array;
> if memavail>sizeof(my_array)+1000 then
>     getmem(p,sizeof(my_array));

This should be

if maxavail >= SizeOf(my_array) then ...

Normally, getmem/freemem shouldn't cause runtime error 202's, because
they allocate memory on the heap, not on the stack. A stack overflow is
usually caused by either too many/too big local variables in a
function/procedure or by some excessive recursion.

If you're sure you're not doing anything wrong, you can increase the
stack space of your application, otherwise it'll just mask the bug so
it occurs later on.

Jonas

Re:Error 202: Stack overflow error.


In article <369A1364.72309...@swipnet.se>,
Tobias Andersson  <T...@swipnet.se> wrote:

Quote
>Where should I start to debug my program? :)

>I get the error when I have allocolated and "freed" memory quite many
>times.

Stack overflow is stack overflow, it has nothing to do with heap.

Quote

>Something like this:

>type     500_105_array : ^my_array;
>            my_array : array[1..500] of string[105];

Identifiers have to begin with a letter.

Quote
>var
>    test : 500_105_array;
>if memavail>sizeof(my_array)+1000 then
>    getmem(p,sizeof(my_array));

Memavail does not guarantee that you can allocate so much. Use maxavail
or better write a new heap error hander.

Quote
>...
>...
>...
>freemem(p,sizeof(my_array);

Have you not heard of new() and dispose()?

Quote
>Can the program chrash if you access memory too often or too "quick"?

Only if you cross your fingers behind your back.

Quote
>But, it's not a loop which allocades and dellocades the memory, it's me
>( :) ) and that means it's not "too" quick or "too" many times before it
>fails.

>I free the memory each time.

>Some thoughs about my problem would be appreciated!

>/Tobias

>Ps. Sorry all the quotes... :) My english is failing today... Ds.

Osmo

Re:Error 202: Stack overflow error.


Ok thanks.
I use maxavail. And, I don't use the same variable names in my program so
that's ok I think.

/Tobias

Quote
Osmo Ronkanen wrote:
> In article <369A1364.72309...@swipnet.se>,
> Tobias Andersson  <T...@swipnet.se> wrote:
> >Where should I start to debug my program? :)

> >I get the error when I have allocolated and "freed" memory quite many
> >times.

> Stack overflow is stack overflow, it has nothing to do with heap.

> >Something like this:

> >type     500_105_array : ^my_array;
> >            my_array : array[1..500] of string[105];

> Identifiers have to begin with a letter.

> >var
> >    test : 500_105_array;
> >if memavail>sizeof(my_array)+1000 then
> >    getmem(p,sizeof(my_array));

> Memavail does not guarantee that you can allocate so much. Use maxavail
> or better write a new heap error hander.

> >...
> >...
> >...
> >freemem(p,sizeof(my_array);

> Have you not heard of new() and dispose()?

> >Can the program chrash if you access memory too often or too "quick"?

> Only if you cross your fingers behind your back.

> >But, it's not a loop which allocades and dellocades the memory, it's me
> >( :) ) and that means it's not "too" quick or "too" many times before it
> >fails.

> >I free the memory each time.

> >Some thoughs about my problem would be appreciated!

> >/Tobias

> >Ps. Sorry all the quotes... :) My english is failing today... Ds.

> Osmo

Re:Error 202: Stack overflow error.


Thanks

I'm a bit unsure about the recursive errors. Maybe that's what I get. How
do they occur? My procedure calls another procedure when it ends, and from
there you can go to the same procedure again. And if you do so many times
my error occurs.

/Tobias
"Lack of interest is my only fear"

Quote
Jonas Maebe wrote:
> In article <369A1364.72309...@swipnet.se>, Tobias Andersson
> <T...@swipnet.se> wrote:

> > type     500_105_array : ^my_array;
> >             my_array : array[1..500] of string[105];
> > var
> >     test : 500_105_array;
> > if memavail>sizeof(my_array)+1000 then
> >     getmem(p,sizeof(my_array));

> This should be

> if maxavail >= SizeOf(my_array) then ...

> Normally, getmem/freemem shouldn't cause runtime error 202's, because
> they allocate memory on the heap, not on the stack. A stack overflow is
> usually caused by either too many/too big local variables in a
> function/procedure or by some excessive recursion.

> If you're sure you're not doing anything wrong, you can increase the
> stack space of your application, otherwise it'll just mask the bug so
> it occurs later on.

> Jonas

Re:Error 202: Stack overflow error.


In article <369A74E4.357BF...@swipnet.se>, Tobias Andersson

Quote
<T...@swipnet.se> wrote:
> I'm a bit unsure about the recursive errors. Maybe that's what I get. How
> do they occur? My procedure calls another procedure when it ends, and from
> there you can go to the same procedure again. And if you do so many times
> my error occurs.

Stack overflows due to recursion usually occur when a
function/procedure keeps calling itself (or calls itself too many
times), bacause every procedure/function call needs a bit of stack
space (the amount depends on the number of parameters and local
variables).

Of course, if you have a construct like

procedure a; forward;

procedure b;
begin
  a
end;

procedure a;
begin
  b
end;

You're going to get that kind of errors as well. Try changing the
structure of your program so that only one procedure calls the other.

Jonas

Re:Error 202: Stack overflow error.


Hello, Thanks again.

When is the space on the stack set free (space which is occupied due to a
procedure call.)? For example if I call a procedure from another and from there
goes to a third procedure. In this example the procedures never goes to "end;".
Causes this the stack to get full? If you want some depth in your program you
must be able to call a procedure from another (, musn't you?).

I suppose I know too little about the memory on the stack, when it's set free
and when it's used.

Maybe you could give me some reading tips? (Preferable, on the net...)

/Tobias

Quote
Jonas Maebe wrote:
> In article <369A74E4.357BF...@swipnet.se>, Tobias Andersson
> <T...@swipnet.se> wrote:

> > I'm a bit unsure about the recursive errors. Maybe that's what I get. How
> > do they occur? My procedure calls another procedure when it ends, and from
> > there you can go to the same procedure again. And if you do so many times
> > my error occurs.

> Stack overflows due to recursion usually occur when a
> function/procedure keeps calling itself (or calls itself too many
> times), bacause every procedure/function call needs a bit of stack
> space (the amount depends on the number of parameters and local
> variables).

> Of course, if you have a construct like

> procedure a; forward;

> procedure b;
> begin
>   a
> end;

> procedure a;
> begin
>   b
> end;

> You're going to get that kind of errors as well. Try changing the
> structure of your program so that only one procedure calls the other.

> Jonas

Re:Error 202: Stack overflow error.


In article <369C91E5.3F0B8...@swipnet.se>,
Tobias Andersson  <T...@swipnet.se> wrote:

Quote
>Hello, Thanks again.

>When is the space on the stack set free (space which is occupied due to a
>procedure call.)?

When the procedure exits.

Quote
> For example if I call a procedure from another and from there
>goes to a third procedure. In this example the procedures never goes to "end;".

Why does it never go to end?`Are you attempting to write some kind of
spaghetti code with the procedure calls. Don't. If you want to do
spaghetti then use goto.

Quote
>Causes this the stack to get full? If you want some depth in your program you
>must be able to call a procedure from another (, musn't you?).

The default stack size of 16KB. That should be enough for normal
purposes.

Osmo

Re:Error 202: Stack overflow error.


Ok... :)

Spaghetti... I feel like I have to rewrite the whole program... A piece of advice,
never even think of learning Basic with all the gotos. It's hard to unlearn bad
habits. :) Even though I haven't programmed that much basic.

So if all procedures must go to end; Then all my procedures have to take parameters.
And I'll have to do a big while loop in the "int main{}" procedure.

The problem is: it's so easy to just call another procedure before you quit  if you
have like:
procedure Hello;
begin
  Write('Choose alternative (1-4): ');
  Readln(my_choose);

  if my_choose = 1 then start_proc_1_which_does_blah_blah;
  if my_choose = 2 then start_proc_2_which_does_blah_blah;
  if my_choose = 3 then start_proc_3_which_does_blah_blah;
  if my_choose = 4 then start_proc_4_which_does_blah_blah;

  (*And from these procedures I usually quit through calling the meny; procedure.
Maybe that's  one big problem. If I would let the "start_proc_1_which....." goto
end; it would terminate and after that go back to the calling procedure which would
terminate too, becuase my_choose isn't equal to any conditions anymore...*)

end;

Well I have to think about this. Thanks for getting me into new thinking. You also
learn by your mistakes I have been told :).

Quote
Osmo Ronkanen wrote:
> In article <369C91E5.3F0B8...@swipnet.se>,
> Tobias Andersson  <T...@swipnet.se> wrote:
> >Hello, Thanks again.

> >When is the space on the stack set free (space which is occupied due to a
> >procedure call.)?

> When the procedure exits.

> > For example if I call a procedure from another and from there
> >goes to a third procedure. In this example the procedures never goes to "end;".

> Why does it never go to end?`Are you attempting to write some kind of
> spaghetti code with the procedure calls. Don't. If you want to do
> spaghetti then use goto.

> >Causes this the stack to get full? If you want some depth in your program you
> >must be able to call a procedure from another (, musn't you?).

> The default stack size of 16KB. That should be enough for normal
> purposes.

> Osmo

Re:Error 202: Stack overflow error.


In article <369CFFB4.84F49...@swipnet.se>, Tobias Andersson

Quote
<T...@swipnet.se> wrote:
>   (*And from these procedures I usually quit through calling the meny;
> procedure.
> Maybe that's  one big problem. If I would let the "start_proc_1_which....."
> goto
> end; it would terminate and after that go back to the calling procedure which
> would
> terminate too, becuase my_choose isn't equal to any conditions anymore...*)

That's indeed the right way to do it. BTW: it's better to use a CASE
statement instead of all those If's.

Jonas

Re:Error 202: Stack overflow error.


In article <369CFFB4.84F49...@swipnet.se>,
Tobias Andersson  <T...@swipnet.se> wrote:

Quote
>Ok... :)

>Spaghetti... I feel like I have to rewrite the whole program... A piece of advice,
>never even think of learning Basic with all the gotos. It's hard to unlearn bad
>habits. :) Even though I haven't programmed that much basic.

>So if all procedures must go to end; Then all my procedures have to take parameters.
>And I'll have to do a big while loop in the "int main{}" procedure.

>The problem is: it's so easy to just call another procedure before you quit  if you
>have like:
>procedure Hello;
>begin
>  Write('Choose alternative (1-4): ');
>  Readln(my_choose);

>  if my_choose = 1 then start_proc_1_which_does_blah_blah;
>  if my_choose = 2 then start_proc_2_which_does_blah_blah;
>  if my_choose = 3 then start_proc_3_which_does_blah_blah;
>  if my_choose = 4 then start_proc_4_which_does_blah_blah;

>  (*And from these procedures I usually quit through calling the meny; procedure.
>Maybe that's  one big problem. If I would let the "start_proc_1_which....." goto
>end; it would terminate and after that go back to the calling procedure which would
>terminate too, becuase my_choose isn't equal to any conditions anymore...*)

Is that some kind of a joke? The proper way is to do something like

 repeat
   Printmenu(choice);
   case choice of
       firstchoice: HandleFirstChoice
       ...
   end;
 until choice=quit;

Quote
>end;

>Well I have to think about this. Thanks for getting me into new thinking. You also
>learn by your mistakes I have been told :).

Osmo

Re:Error 202: Stack overflow error.


Ok, I understand now. Thanks you have all helped me to get into a new way of
thinking.

Btw. Is case faster than ifs, like inc(y) is faster than y:=y+1;? (I know case
gives a good structure to the code, in some cases.)

/Tobias

Re:Error 202: Stack overflow error.


In article <369E32AE.29B92...@swipnet.se>, Tobias Andersson

Quote
<T...@swipnet.se> wrote:
> Btw. Is case faster than ifs, like inc(y) is faster than y:=y+1;? (I know case
> gives a good structure to the code, in some cases.)

Inc(i) isn't necessarily faster than i := i + 1, and likewise case
isn't necessarily faster than a bunch of if's. It all depends on the
compiler you're using.

Jonas

Re:Error 202: Stack overflow error.


In article <369E32AE.29B92...@swipnet.se>,
Tobias Andersson  <T...@swipnet.se> wrote:

Quote
>Ok, I understand now. Thanks you have all helped me to get into a new way of
>thinking.

>Btw. Is case faster than ifs, like inc(y) is faster than y:=y+1;? (I know case
>gives a good structure to the code, in some cases.)

On BP/TP case is faster as the selector value is loaded into a register
at  the beginning. As for the inc(y), on Pentium y:=y+1 is actually
faster because it allows pairing with other instructions.

Osmo

Re:Error 202: Stack overflow error.


Tobias Andersson [mailto:T...@swipnet.se] decided to regale us with

Quote
>Ok, I understand now. Thanks you have all helped me to get into a new way of
>thinking.

>Btw. Is case faster than ifs,

Depends somewhat on the compiler [you have posted to clpm and clpb so we
cannot determine which compiler you use] but a simple if..then..else
will be at least as quick as a case statement. Case statements are going
to be quicker the more options you have as Case keeps the switch in a
register

Quote
>like inc(y) is faster than y:=y+1;?

Again can depend on the compiler, and also in this case on the CPU. the
Add instruction [using y:=y+1;] is, IIRC, pairable whilst inc(y) is not
so *may* execute faster on x5(86) and above CPU's

The differences however will only be discernable in execution time if
they need to be carried a *lot* of times. For one-off usage then use
which seems more logical and clearer at the time.

--
Pedt

Go to page: [1] [2]

Other Threads