Board index » delphi » Stack overflow

Stack overflow

Quote
In article <sinykal.475.000AB...@{*word*104}space.org> Scott Earnest wrote:
>In article <sinykal.474.00098...@{*word*104}space.org> siny...@{*word*104}space.org(Scott Earnest) writes:

>Hmmm, okay.  I've taken a little time to pull this down and look at it and
>there are a couple problems -- just what I get for working blind.  First,
>two omissions keep it from working.  Second . . . well, I'll get to that.

[ snip ]

>Now, even with that done, it doesn't produce useful results.  It always
>seems to give a worthless answer, always around 2K.  I tested it with stack
>sizes of 16K and 4K (sufficiently different, I think), and one gave 2344,
>and the other 2042, respectively.  Also tested with programs that use
>recursive procedures (directory tree walker).  Any ideas why this could be
>happening?  Some things I thought of and tried:

>- Get BP rather than SP.  Same wrong number.
>- Make tmpstack local.  Same wrong number, but 2 bytes off.
>- Tried without parameters to save registers.  Nope.
>- Only check the value of SP if the InDOS flag is clear (something I had to
>  do in another ISR I just wrote).

>One theory I have is that DS might not be valid when the interrupt is
>called, so [tmpstack] might be a meaningless address.  Is it safe to call
>DSeg in an ISR, and if so, does can it be relied upon to return the correct
>value of DS?

>I'd like to figure out both why this doesn't work, and how to make it work.
>This would make a useful testing tool.  Well, at least the ISR structuring
>is correct, and it doesn't crash.

[ snip ]

This is a clasic case of code doing exactly what you asked, which is
not necessayily what you wanted.  You are accurately measuring the
amount of free space remaining in the system's current interrupt stack.  
But you knew that... :)

In regards to your previous question -
Yes - SP can be moved directly to/from mempry
Yes - Not only is DS, but all registers and flags are undefined.
Yes - DSeg and @Data can be accessed from within an interrupt service
      and they will have the correct values for your program which
      will be accessed as a literal that was fixed by the loader when
      the program was loaded.

--
Roger E. Donais
RDon...@gnn.com
http://members.gnn.com/rdonais/index.html
-------------------------------------------
Knowledge is one of the few things that you
can give away and still keep for yourself.

 

Re:Stack overflow


Re:Stack overflow


In article <6Bo8fezE...@site33.ping.at> of Sat, 29 Jun 1996 12:15:00 in
comp.lang.pascal.borland, Chris Mathews <rse...@site33.ping.at> wrote:

Quote
>On a slightly different subject, does anyone know how to monitor the size of  
>the stack (i.e., how much is still available)?  I don't know of any way to  
>set the stack size for a given program except trial and error.

Check SPtr in the Manual / Help.

AIUI, SPtr starts at the amount set by {$M ...} or default, and
diminishes as you use stack.

--
John Stockton, Surrey, UK.  J...@merlyn.demon.co.uk  Turnpike v1.12  MIME
    Home Page under construction.

Re:Stack overflow


H|!

Quote
>Just for your information: We discovered another bug, which is
>maybe stack releated, too:

>The "WITH" statement can't be used recursively.
>Example, that will fail:

TYPE
  TMyType1 = RECORD
    test : BYTE;
  END;
  TMyType2 = RECORD
    test : BYTE;
  END;

PROCEUDRE TESTIT;
VAR
  t1,t2 : TMyType;
BEGIN
  WITH t1 DO BEGIN
    test:=1;
    WITH t2 DO BEGIN
      test:=2;
    END;
    test:=3;
{here it goes wrong, instead of writing to t1.test it overwrites
t2.test}
  END;

There is no any stack using there, it's all up to compiler like various
{$IFDEF }, {$ENDIF} etc..
I that is a compiler bug, it should give a compiler error there or write into
t1.test .

                                              SBR.
---
Bu...@stk.ksu.ras.ru
{Excuse me please for my bad russian, my native language is DELPHI 32-bit}

Re:Stack overflow


Quote
rse...@site33.ping.at (Chris Mathews) writes:
>On a slightly different subject, does anyone know how to monitor the size of  
>the stack (i.e., how much is still available)?  I don't know of any way to  
>set the stack size for a given program except trial and error.

What I do is to fill the stack segment (from 0 to <SP) with a certain pattern
at the beginning of the program, and to check how much of the pattern is left
at the end of the program. This gives the amount of unused stack.

Note, however, to keep some bytes in reserve (for interrupts etc.), and that
stack usage may depend on what the user of the program does. (You must make
sure to get the maximum stack usage when testing.)

Hope this helps,
Frank

Re:Stack overflow


Re:Stack overflow


Quote
siny...@{*word*104}space.org (Scott Earnest) writes:
>In article <sinykal.474.00098...@{*word*104}space.org> siny...@{*word*104}space.org (Scott Earnest) writes:
>Now, even with that done, it doesn't produce useful results.  It always
>seems to give a worthless answer, always around 2K.  I tested it with stack
>sizes of 16K and 4K (sufficiently different, I think), and one gave 2344,
>and the other 2042, respectively.  Also tested with programs that use
>recursive procedures (directory tree walker).  Any ideas why this could be
>happening?  Some things I thought of and tried:
>- Get BP rather than SP.  Same wrong number.
>- Make tmpstack local.  Same wrong number, but 2 bytes off.
>- Tried without parameters to save registers.  Nope.

It actually doesn't matter if you declare the parameters. BP will save
the registers anyway.

Quote
>- Only check the value of SP if the InDOS flag is clear (something I had to
>  do in another ISR I just wrote).

I think the problem is that sometimes when the interrupt occurs, another
stack than the program's is active. Is doesn't have to be a Dos stack, so
testing InDos won't help much - it may be a local stack of some device
driver or anything...

What I would do is to check if the value of SS equals the value of your
program's stack segment. This should give some useful results (not tested,
however). Anyway, you won't get the maximum stack usage, but only a
number more or less close to the maximum, because the interrupt won't
probably occur exactly at the time of maximum usage. So I'd still
prefer the solution I posted in another article - besides, it's easier.

Quote
>One theory I have is that DS might not be valid when the interrupt is
>called, so [tmpstack] might be a meaningless address.  Is it safe to call
>DSeg in an ISR, and if so, does can it be relied upon to return the correct
>value of DS?

BP saves all registers and loads DS correctly in a procedure declared as
interrupt. So, DS is valid.

Hope this helps,
Frank

Re:Stack overflow


In article <4rb38t$...@rznews.rrze.uni-erlangen.de> fkhec...@cip.informatik.uni-erlangen.de (Frank Heckenbach) writes:

Quote
>siny...@{*word*104}space.org (Scott Earnest) writes:
>>In article <sinykal.474.00098...@{*word*104}space.org> siny...@{*word*104}space.org
>(Scott Earnest) writes:
>>Now, even with that done, it doesn't produce useful results.  It always
>>seems to give a worthless answer, always around 2K.  I tested it with stack
>>sizes of 16K and 4K (sufficiently different, I think), and one gave 2344,
>>and the other 2042, respectively.  Also tested with programs that use
>>recursive procedures (directory tree walker).  Any ideas why this could be
>>happening?  Some things I thought of and tried:
>>- Get BP rather than SP.  Same wrong number.
>>- Make tmpstack local.  Same wrong number, but 2 bytes off.
>>- Tried without parameters to save registers.  Nope.
>It actually doesn't matter if you declare the parameters. BP will save
>the registers anyway.
>>- Only check the value of SP if the InDOS flag is clear (something I had to
>>  do in another ISR I just wrote).
>I think the problem is that sometimes when the interrupt occurs, another
>stack than the program's is active. Is doesn't have to be a Dos stack, so
>testing InDos won't help much - it may be a local stack of some device
>driver or anything...

That appears to be the case.

Quote
>What I would do is to check if the value of SS equals the value of your
>program's stack segment. This should give some useful results (not tested,
>however). Anyway, you won't get the maximum stack usage, but only a
>number more or less close to the maximum, because the interrupt won't
>probably occur exactly at the time of maximum usage. So I'd still
>prefer the solution I posted in another article - besides, it's easier.

I think I tried this, and it still didn't seem to want to work.  Maybe I was
doing something wrong, but for curiosity's sake, I'll double check it.

Quote
>>One theory I have is that DS might not be valid when the interrupt is
>>called, so [tmpstack] might be a meaningless address.  Is it safe to call
>>DSeg in an ISR, and if so, does can it be relied upon to return the correct
>>value of DS?
>BP saves all registers and loads DS correctly in a procedure declared as
>interrupt. So, DS is valid.

Something I've also discovered -- you *can't* call DSeg because, even though
the manual says it's a function, it's not -- it's a global variable (at
least in BP 7 real mode, I haven't checked it yet in the other targets).  
And now that I think about it, what you say makes sense (about DS being
valid).  If DS were invalid, the stackmin variable wouldn't change.

I did read your other message, and that definitely sounds like a better way
to go about finding the answer.

Quote
>Hope this helps,
>Frank

--
Scott Earnest          | We now return you to our regularly scheduled |
siny...@{*word*104}space.org | chaos and mayhem. . . .                      |

Re:Stack overflow


Quote
siny...@{*word*104}space.org (Scott Earnest) writes:
> Something I've also discovered -- you *can't* call DSeg because, even though
> the manual says it's a function, it's not -- it's a global variable (at
> least in BP 7 real mode, I haven't checked it yet in the other targets).

Actually, it's not a global variable - that wouldn't make much sense, would it?
A variable in the DS containing the value of DS...

I checked with BP 7 for all three targets, dseg just generates a "mov ax,ds".
So it behaves like a usual inline function:
function dseg:word; inline($8C/$D8);

Quote
> I did read your other message, and that definitely sounds like a better way
> to go about finding the answer.

I've been using it for some time without problems. AFAIK, it works only in
real mode. But you may get it to work for the other platforms, too...
(As you probably know, in these modes data, stack and local heap are in the
same segment, and I don't know where the stack starts.)

Frank

Re:Stack overflow


In article <4rgihv$...@rznews.rrze.uni-erlangen.de> fkhec...@cip.informatik.uni-erlangen.de (Frank Heckenbach) writes:

Quote
>siny...@{*word*104}space.org (Scott Earnest) writes:
>> Something I've also discovered -- you *can't* call DSeg because, even though
>> the manual says it's a function, it's not -- it's a global variable (at
>> least in BP 7 real mode, I haven't checked it yet in the other targets).
>Actually, it's not a global variable - that wouldn't make much sense, would
>it?
>A variable in the DS containing the value of DS...
>I checked with BP 7 for all three targets, dseg just generates a "mov ax,ds".
>So it behaves like a usual inline function:
>function dseg:word; inline($8C/$D8);

Ah, that makes more sense now!  functions and procedures declared with the
inline directive aren't callable from BASM.  I hadn't thought of that.

Quote
>> I did read your other message, and that definitely sounds like a better

way>> to go about finding the answer.

Quote
>I've been using it for some time without problems. AFAIK, it works only in
>real mode. But you may get it to work for the other platforms, too...
>(As you probably know, in these modes data, stack and local heap are in the
>same segment, and I don't know where the stack starts.)

Protected mode is similar to real mode in that it has its own independent
stack segment (or so the Language Guide tells me), so it might still work
(the worst that could happen is a GPF, right?).  Windows is the ugly one,
with its automatic data segment.  I really can't make any suggestions to an
approach for that, since I don't do Windows.  :-)

Quote
>Frank

--
Scott Earnest          | We now return you to our regularly scheduled |
siny...@{*word*104}space.org | chaos and mayhem. . . .                      |
Go to page: [1] [2]

Other Threads