Re: stack frame too large

["Marc A. Criley" <mcquad@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