Re: stack frame too large

["Wayne Lydecker" <wlydeckr@pacbell.net>]

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.