stack frame too large

stack frame too large

[wayne lydecker]

We are experiencing a rather severe error using Alsys on HP.
Evidently we are overflowing a stack frame which is causing
a corrupted heap.  Because I am playing with GNAT, I decided
to see if I can get more information using that compiler while
using the -fstack-check switch.  GNAT does indeed complain:

    frame size too large for reliable stack checking
    try reducing the number of local variables

I have been able to distill the error down to a very fundamental
set of code.  If I call a procedure that calls a function to
return an array of 2000 integers, I get the error.  1000
integers works fine.  If anyone can shed light on this unusual
problem, I would be most grateful.  I compile it with:

gnatmake -g test -cargs -fstack-check 

Here's the exact warning from GNAT:

fifo_queue.adb: In function `fifo_queue__deque':
fifo_queue.adb:11: warning: frame size too large for reliable stack checking
fifo_queue.adb:11: warning: try reducing the number of local variables

Here's the code (suitable for gnatchop).

Thanks,

-- Wayne.

package Fifo_Queue is

  type Data_Type is array (1..2000) of Integer;

  procedure Deque (Data : out Data_Type);

end Fifo_Queue;

package body Fifo_Queue is
  My_Data : Data_Type := (others => 0);

  function Deque return Data_Type is
  begin 
    return My_Data;
  end Deque;

  procedure Deque (Data  : out Data_Type) is
  begin
    Data := Deque; -- Line 11 as reported in warning.
  end Deque;

end Fifo_Queue;

with fifo_queue;
procedure test is
begin
  null;
end;

Re: stack frame too large

[Marc A. Criley]

wayne lydecker wrote:
> 
> We are experiencing a rather severe error using Alsys on HP.
> Evidently we are overflowing a stack frame which is causing
> a corrupted heap.  Because I am playing with GNAT, I decided
> to see if I can get more information using that compiler while
> using the -fstack-check switch.  GNAT does indeed complain:
> 
>     frame size too large for reliable stack checking
>     try reducing the number of local variables
> 
> I have been able to distill the error down to a very fundamental
> set of code.  If I call a procedure that calls a function to
> return an array of 2000 integers, I get the error.  1000
> integers works fine.  If anyone can shed light on this unusual
> problem, I would be most grateful.  I compile it with:
> 
> gnatmake -g test -cargs -fstack-check
> 
> Here's the exact warning from GNAT:
> 
> fifo_queue.adb: In function `fifo_queue__deque':
> fifo_queue.adb:11: warning: frame size too large for reliable stack checking
> fifo_queue.adb:11: warning: try reducing the number of local variables
> 
> Here's the code (suitable for gnatchop).
> 
> Thanks,
> 
> -- Wayne.
> 
  <snip>

Yep, I was encountering that warning a few months ago with code we were
compiling with GNAT when I was back at Lockheed Martin.

I don't recall the detailed explanation of how all the stack frame
checking works, but the bottom line was that we were attempting to pass
back more data on the stack than could be reliably verified as not
causing a stack overflow, given the current usage of that particular
stack frame.

If you eat up a lot of stack space with local variables, especially if
they're large, you can seriously reduce the amount of stack space
available for passing data items.  In practice, we found that
recommendation to be bogus, the problem was never with the number/size
of local variables.

We worked around the stack warnings like this:

In the specific case you presented, we simply converted the functions
to procedures and returned the data in an 'out' parameter.

Assignments using large aggregates also sometimes caused frame size
warnings, those we dealt with by doing field-by-field assignments.
Tedious, and defeats the purpose of aggregates, but we preferred good
stack checking and reliability :-)

There was another case where passing a large record object that was
_partially_ rep-speced would generate this warning, while if there
was no rep spec, or if it was fully rep speced, there'd be no warning.
That was a compiler bug, and was fixed for GNAT 3.14 I believe.

Hope this helps,

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation

Re: stack frame too large

[Wayne Lydecker]

Marc A. Criley <mcquad@earthlink.net> wrote in message
news:3A0D4A91.8C219079@earthlink.net...
> wayne lydecker wrote:
> >
> > We are experiencing a rather severe error using Alsys on HP.
> > Evidently we are overflowing a stack frame which is causing
> > a corrupted heap.  Because I am playing with GNAT, I decided
> > to see if I can get more information using that compiler while
> > using the -fstack-check switch.  GNAT does indeed complain:
> >
> >     frame size too large for reliable stack checking
> >     try reducing the number of local variables
> >
> > I have been able to distill the error down to a very fundamental
> > set of code.  If I call a procedure that calls a function to
> > return an array of 2000 integers, I get the error.  1000
> > integers works fine.  If anyone can shed light on this unusual
> > problem, I would be most grateful.  I compile it with:
> >
> > gnatmake -g test -cargs -fstack-check
> >
> > Here's the exact warning from GNAT:
> >
> > fifo_queue.adb: In function `fifo_queue__deque':
> > fifo_queue.adb:11: warning: frame size too large for reliable stack checking
> > fifo_queue.adb:11: warning: try reducing the number of local variables
> >
> > Here's the code (suitable for gnatchop).
> >
> > Thanks,
> >
> > -- Wayne.
> >
>   <snip>
>
> Yep, I was encountering that warning a few months ago with code we were
> compiling with GNAT when I was back at Lockheed Martin.
>
> I don't recall the detailed explanation of how all the stack frame
> checking works, but the bottom line was that we were attempting to pass
> back more data on the stack than could be reliably verified as not
> causing a stack overflow, given the current usage of that particular
> stack frame.
>
> If you eat up a lot of stack space with local variables, especially if
> they're large, you can seriously reduce the amount of stack space
> available for passing data items.  In practice, we found that
> recommendation to be bogus, the problem was never with the number/size
> of local variables.
>
> We worked around the stack warnings like this:
>
> In the specific case you presented, we simply converted the functions
> to procedures and returned the data in an 'out' parameter.
>
> Assignments using large aggregates also sometimes caused frame size
> warnings, those we dealt with by doing field-by-field assignments.
> Tedious, and defeats the purpose of aggregates, but we preferred good
> stack checking and reliability :-)
>
> There was another case where passing a large record object that was
> _partially_ rep-speced would generate this warning, while if there
> was no rep spec, or if it was fully rep speced, there'd be no warning.
> That was a compiler bug, and was fixed for GNAT 3.14 I believe.
>
> Hope this helps,
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation

Thanks, that does help.  Why is there a limit on the stack frame size?
I played with the above example some more last night and found that
between 1,017 and 1,018 integers (<4Kb) the warning is generated.  I
was hoping I could throw a compile, link, or run switch to bump up the
stack frame size.

Another solution to the problem will be to use pointers.  Unfortunately,
there are many instances of this in our code and none of them are nearly
as simple as the above example.

Thanks again,

-- Wayne.

Re: stack frame too large

[Jeff Creem]

Stuff Deleted
>
> Thanks, that does help.  Why is there a limit on the stack frame size?
> I played with the above example some more last night and found that
> between 1,017 and 1,018 integers (<4Kb) the warning is generated.  I
> was hoping I could throw a compile, link, or run switch to bump up the
> stack frame size.
>
> Another solution to the problem will be to use pointers.  Unfortunately,
> there are many instances of this in our code and none of them are nearly
> as simple as the above example.
>
> Thanks again,
>
> -- Wayne.
>
>

You can easily increase the stack size for your tasks with rep specs
and the mainline program task with unix commands (assuming csh)
limit stacksize  SOMEBIGNUMBER

The limit that GNAT is talking about here is a limit for reliable stack
frame
size error detection. I suspect what is happening here is (and this is a
guess -
a gcc/gnat guru could answer this better), is that the stack checks that
GNAT
emits are done by allocating a non R/W block of memory at the top of the
stack so
that if something spills into it a "interrupt" is cause by the runtime. THe
problem is that
with large single variables it might jump all the way past the "protected"
frame and if no accesses
were done within the protected area no error would be detected. (or
something a little like this).

The other way for a compiler to detect stack size problems is to insert code
that checks the
stack pointer before/after each expansion. This is probably a little slower
and also does
not detect the case when an Ada call to a C routine is done and the C
routine
overflows the stack....

Re: stack frame too large

[David Starner]

On Fri, 10 Nov 2000 17:24:08 -0800, wayne lydecker wrote:
>I have been able to distill the error down to a very fundamental
>set of code.  If I call a procedure that calls a function to
>return an array of 2000 integers, I get the error.  1000
>integers works fine.  If anyone can shed light on this unusual
>problem, I would be most grateful.  I compile it with:

It seems clear to me - the compilers don't like trying to pass
that large an item by stack. Your best bet is probably to
allocate memory on the heap and pass a pointer.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
As centuries of pulp novels and late-night Christian broadcasting have taught 
us, anything we don't understand can be used for the purposes of Evil.
	-- Kenneth Hite, Suppressed Transmissions

Re: stack frame too large

[Marc A. Criley]

Wayne Lydecker wrote:
> 
  <snip>
> 
> Thanks, that does help.  Why is there a limit on the stack frame size?
> I played with the above example some more last night and found that
> between 1,017 and 1,018 integers (<4Kb) the warning is generated.  I
> was hoping I could throw a compile, link, or run switch to bump up the
> stack frame size.
> 
> Another solution to the problem will be to use pointers.  Unfortunately,
> there are many instances of this in our code and none of them are nearly
> as simple as the above example.

After posting my earlier response, I did remember that in a few cases
we were able to use pointers.  If the data being returned by a function
was for reference purposes only, i.e., it wasn't going to be modified,
then we "aliased" the data structure and returned a pointer to it via
'Access.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation