Re: What task storage_size to use?

Re: What task storage_size to use?

[Michael Rowley]

This thread may be of interest to people other than Gnat users, so I am
cross-posting from the Gnat chat mailing list, where it started, to the
comp.lang.ada newsgroup.

The topic regards trying to determine the appropriate Storage_Size to
use for a stack, possibly assuming that the programmer already knows
what the frame stack will look like when it is the deepest (i.e. what
function calls are on it).

Robert I. Eachus wrote:
> 
> At 04:24 PM 11/19/97 +0100, CHARLET Arnaud wrote:
> >In the current version of gdb for GNAT, this problem is very easy
> >to solve since gdb gives you the stack size and % of stack used for each
> >task.
> 
>    Which gives a useful number in many cases.  However, as Mike Brenner was
> saying, the halting problem can be embedded in the general case.  If those
> words don't mean anything to you, translate it as "well beyond impossible."

I think I like Arno's answer better.  His answer implies that I should
run my program such that tasks are running as large a frame stack as I
think they will ever encounter, then look at GDB to determine that size,
and possibly choose a larger number.

Robert's answer is less useful.  Knowing it's impossible to determine
the maximum size in general (which isn't news), doesn't help me.  Does
it mean I shouldn't use tasks?  Does it mean I should just use the
default task storage_size, and then if I run the program and find that
stack overflow is overwriting non-stack memory, I should then up the
stack size and try again?

Another approach that I am thinking of using is to create my own
Storage_Pool for the task access type, which would allocate one more
page than necessary for the task and write protect the extra page.  Then
if there is a page fault on that page I would know that I am within one
page of running out of stack space, and then try to recover gracefully.

Michael Rowley
rowley@inmet.com

Re: What task storage_size to use?

[Matthew Heaney]

In article <34785EC5.740B76B0@intermetrics.com>, Michael Rowley
<rowley@intermetrics.com> wrote:

>Another approach that I am thinking of using is to create my own
>Storage_Pool for the task access type, which would allocate one more
>page than necessary for the task and write protect the extra page.  Then
>if there is a page fault on that page I would know that I am within one
>page of running out of stack space, and then try to recover gracefully.

I don't get it.  Why don't you just catch Storage_Error?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: What task storage_size to use?

[Michael Rowley]

Matthew Heaney wrote:
> 
> In article <34785EC5.740B76B0@intermetrics.com>, Michael Rowley
> <rowley@intermetrics.com> wrote:
> 
> >Another approach that I am thinking of using is to create my own
> >Storage_Pool for the task access type, which would allocate one more
> >page than necessary for the task and write protect the extra page.  Then
> >if there is a page fault on that page I would know that I am within one
> >page of running out of stack space, and then try to recover gracefully.
> 
> I don't get it.  Why don't you just catch Storage_Error?

Two reasons.  First, at least as of Gnat3.07 or so (I haven't checked
recently) overflowing the stack didn't generate a storage error. 
Apparently, according to Robert Dewar, that is now fixed.

Second.  It would be very difficult for me to clean up after a storage
error that could have happened at almost any place in my program.  There
are certain places in my program where I would like to be able to ask:
am I almost out of stack space?  If I did the memory protection scheme
that I mentioned above, I would NOT generate an exception.  Instead, I
would unprotect the page and then set a global variable, which would be
checked before the stack got much deeper.  That variable would signify
that I better stop growing the stack now.

Michael Rowley
rowley@inmet.com

Re: What task storage_size to use?

[Robert Dewar]

Michael said

<<Two reasons.  First, at least as of Gnat3.07 or so (I haven't checked
recently) overflowing the stack didn't generate a storage error.
Apparently, according to Robert Dewar, that is now fixed.

Second.  It would be very difficult for me to clean up after a storage
error that could have happened at almost any place in my program.  There
are certain places in my program where I would like to be able to ask:
am I almost out of stack space?  If I did the memory protection scheme
that I mentioned above, I would NOT generate an exception.  Instead, I
would unprotect the page and then set a global variable, which would be
checked before the stack got much deeper.  That variable would signify
that I better stop growing the stack now.
>>


Well 3.07 is indeed truly ancient at this stage, and indeed, on some
targets, lacked stack overflow checking, but the current version of
GNAT supports stack overflow checking. The algorithm used by GNAT allows
for a stack buffer space which is guaranteed available when a storage
error is signalled.

You can trivially adjust this buffer size to meet your needs, and just
set the global variable in a storage error handler (actually it had
better NOT be a global variable, but rather a task specific one, use
task_Attributes if necessary).

Re: What task storage_size to use?

[Robert Dewar]

Matthew replies

<<>Another approach that I am thinking of using is to create my own
>Storage_Pool for the task access type, which would allocate one more
>page than necessary for the task and write protect the extra page.  Then
>if there is a page fault on that page I would know that I am within one
>page of running out of stack space, and then try to recover gracefully.

I don't get it.  Why don't you just catch Storage_Error?
>>


Indeed, and that is in fact *how* GNAT implements the check for
Storage_Error with respect to stack allocation!