* stack frame too large @ 2000-11-10 0:00 wayne lydecker 2000-11-11 0:00 ` David Starner 2000-11-11 0:00 ` Marc A. Criley 0 siblings, 2 replies; 6+ messages in thread From: wayne lydecker @ 2000-11-10 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stack frame too large 2000-11-10 0:00 stack frame too large wayne lydecker @ 2000-11-11 0:00 ` David Starner 2000-11-11 0:00 ` Marc A. Criley 1 sibling, 0 replies; 6+ messages in thread From: David Starner @ 2000-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stack frame too large 2000-11-10 0:00 stack frame too large wayne lydecker 2000-11-11 0:00 ` David Starner @ 2000-11-11 0:00 ` Marc A. Criley 2000-11-11 0:00 ` Wayne Lydecker 1 sibling, 1 reply; 6+ messages in thread From: Marc A. Criley @ 2000-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stack frame too large 2000-11-11 0:00 ` Marc A. Criley @ 2000-11-11 0:00 ` Wayne Lydecker 2000-11-11 0:00 ` Jeff Creem 2000-11-12 0:00 ` Marc A. Criley 0 siblings, 2 replies; 6+ messages in thread From: Wayne Lydecker @ 2000-11-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stack frame too large 2000-11-11 0:00 ` Wayne Lydecker @ 2000-11-11 0:00 ` Jeff Creem 2000-11-12 0:00 ` Marc A. Criley 1 sibling, 0 replies; 6+ messages in thread From: Jeff Creem @ 2000-11-11 0:00 UTC (permalink / raw) 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.... ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stack frame too large 2000-11-11 0:00 ` Wayne Lydecker 2000-11-11 0:00 ` Jeff Creem @ 2000-11-12 0:00 ` Marc A. Criley 1 sibling, 0 replies; 6+ messages in thread From: Marc A. Criley @ 2000-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-11-12 0:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-10 0:00 stack frame too large wayne lydecker 2000-11-11 0:00 ` David Starner 2000-11-11 0:00 ` Marc A. Criley 2000-11-11 0:00 ` Wayne Lydecker 2000-11-11 0:00 ` Jeff Creem 2000-11-12 0:00 ` Marc A. Criley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox