* Re: What task storage_size to use? [not found] ` <3.0.1.32.19971121191820.00b96cf0@spectre.mitre.org> @ 1997-11-23 0:00 ` Michael Rowley 1997-11-23 0:00 ` Matthew Heaney 0 siblings, 1 reply; 5+ messages in thread From: Michael Rowley @ 1997-11-23 0:00 UTC (permalink / raw) To: Robert I. Eachus This thread may be of interest to people other than Gnat users, so I am cross-posting from the Gnat chat mailing list, where it started, to the comp.lang.ada newsgroup. The topic regards trying to determine the appropriate Storage_Size to use for a stack, possibly assuming that the programmer already knows what the frame stack will look like when it is the deepest (i.e. what function calls are on it). Robert I. Eachus wrote: > > At 04:24 PM 11/19/97 +0100, CHARLET Arnaud wrote: > >In the current version of gdb for GNAT, this problem is very easy > >to solve since gdb gives you the stack size and % of stack used for each > >task. > > Which gives a useful number in many cases. However, as Mike Brenner was > saying, the halting problem can be embedded in the general case. If those > words don't mean anything to you, translate it as "well beyond impossible." I think I like Arno's answer better. His answer implies that I should run my program such that tasks are running as large a frame stack as I think they will ever encounter, then look at GDB to determine that size, and possibly choose a larger number. Robert's answer is less useful. Knowing it's impossible to determine the maximum size in general (which isn't news), doesn't help me. Does it mean I shouldn't use tasks? Does it mean I should just use the default task storage_size, and then if I run the program and find that stack overflow is overwriting non-stack memory, I should then up the stack size and try again? Another approach that I am thinking of using is to create my own Storage_Pool for the task access type, which would allocate one more page than necessary for the task and write protect the extra page. Then if there is a page fault on that page I would know that I am within one page of running out of stack space, and then try to recover gracefully. Michael Rowley rowley@inmet.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What task storage_size to use? 1997-11-23 0:00 ` What task storage_size to use? Michael Rowley @ 1997-11-23 0:00 ` Matthew Heaney 1997-11-24 0:00 ` Robert Dewar 1997-11-24 0:00 ` Michael Rowley 0 siblings, 2 replies; 5+ messages in thread From: Matthew Heaney @ 1997-11-23 0:00 UTC (permalink / raw) In article <34785EC5.740B76B0@intermetrics.com>, Michael Rowley <rowley@intermetrics.com> wrote: >Another approach that I am thinking of using is to create my own >Storage_Pool for the task access type, which would allocate one more >page than necessary for the task and write protect the extra page. Then >if there is a page fault on that page I would know that I am within one >page of running out of stack space, and then try to recover gracefully. I don't get it. Why don't you just catch Storage_Error? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What task storage_size to use? 1997-11-23 0:00 ` Matthew Heaney @ 1997-11-24 0:00 ` Robert Dewar 1997-11-24 0:00 ` Michael Rowley 1 sibling, 0 replies; 5+ messages in thread From: Robert Dewar @ 1997-11-24 0:00 UTC (permalink / raw) Matthew replies <<>Another approach that I am thinking of using is to create my own >Storage_Pool for the task access type, which would allocate one more >page than necessary for the task and write protect the extra page. Then >if there is a page fault on that page I would know that I am within one >page of running out of stack space, and then try to recover gracefully. I don't get it. Why don't you just catch Storage_Error? >> Indeed, and that is in fact *how* GNAT implements the check for Storage_Error with respect to stack allocation! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What task storage_size to use? 1997-11-23 0:00 ` Matthew Heaney 1997-11-24 0:00 ` Robert Dewar @ 1997-11-24 0:00 ` Michael Rowley 1997-11-24 0:00 ` Robert Dewar 1 sibling, 1 reply; 5+ messages in thread From: Michael Rowley @ 1997-11-24 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > In article <34785EC5.740B76B0@intermetrics.com>, Michael Rowley > <rowley@intermetrics.com> wrote: > > >Another approach that I am thinking of using is to create my own > >Storage_Pool for the task access type, which would allocate one more > >page than necessary for the task and write protect the extra page. Then > >if there is a page fault on that page I would know that I am within one > >page of running out of stack space, and then try to recover gracefully. > > I don't get it. Why don't you just catch Storage_Error? Two reasons. First, at least as of Gnat3.07 or so (I haven't checked recently) overflowing the stack didn't generate a storage error. Apparently, according to Robert Dewar, that is now fixed. Second. It would be very difficult for me to clean up after a storage error that could have happened at almost any place in my program. There are certain places in my program where I would like to be able to ask: am I almost out of stack space? If I did the memory protection scheme that I mentioned above, I would NOT generate an exception. Instead, I would unprotect the page and then set a global variable, which would be checked before the stack got much deeper. That variable would signify that I better stop growing the stack now. Michael Rowley rowley@inmet.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What task storage_size to use? 1997-11-24 0:00 ` Michael Rowley @ 1997-11-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 5+ messages in thread From: Robert Dewar @ 1997-11-24 0:00 UTC (permalink / raw) Michael said <<Two reasons. First, at least as of Gnat3.07 or so (I haven't checked recently) overflowing the stack didn't generate a storage error. Apparently, according to Robert Dewar, that is now fixed. Second. It would be very difficult for me to clean up after a storage error that could have happened at almost any place in my program. There are certain places in my program where I would like to be able to ask: am I almost out of stack space? If I did the memory protection scheme that I mentioned above, I would NOT generate an exception. Instead, I would unprotect the page and then set a global variable, which would be checked before the stack got much deeper. That variable would signify that I better stop growing the stack now. >> Well 3.07 is indeed truly ancient at this stage, and indeed, on some targets, lacked stack overflow checking, but the current version of GNAT supports stack overflow checking. The algorithm used by GNAT allows for a stack buffer space which is guaranteed available when a storage error is signalled. You can trivially adjust this buffer size to meet your needs, and just set the global variable in a storage error handler (actually it had better NOT be a global variable, but rather a task specific one, use task_Attributes if necessary). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1997-11-24 0:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3472A748.213DF2CA@intermetrics.com> [not found] ` <3.0.1.32.19971121191820.00b96cf0@spectre.mitre.org> 1997-11-23 0:00 ` What task storage_size to use? Michael Rowley 1997-11-23 0:00 ` Matthew Heaney 1997-11-24 0:00 ` Robert Dewar 1997-11-24 0:00 ` Michael Rowley 1997-11-24 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox