From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ea99a8822847633f X-Google-Attributes: gid103376,public From: "Marc A. Criley" Subject: Re: stack frame too large Date: 2000/11/11 Message-ID: <3A0D4A91.8C219079@earthlink.net>#1/1 X-Deja-AN: 692393181 Content-Transfer-Encoding: 7bit References: <3A0C9FB8.9EBC9A7F@pacbell.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 973953346 158.252.123.93 (Sat, 11 Nov 2000 06:35:46 PST) Organization: Quadrus Corporation MIME-Version: 1.0 NNTP-Posting-Date: Sat, 11 Nov 2000 06:35:46 PST Newsgroups: comp.lang.ada Date: 2000-11-11T00:00:00+00:00 List-Id: 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. > 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