Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.programmer.misc > #236

Re: Avoiding recursive stack overflow in C?

Cross-posted to 4 groups.

Show all headers | View raw

> [...] Where's the buzzer/warning light for approaching the stack 
> limits in C? The non-portable best that I can do is handling SIGSEGV, 
> which is a little late; the problem I wanted to avoid has already 
> happened by the time that signal is raised.  For that matter, I'd 
> settle for the analog of a gas gauge - where can I find it?
>
For what it's worth, if you expand your horizons outside of just Unix 
and Linux, things are rather different.  For one thing, the problem that 
you want to avoid has not "already happened" on systems such as Win32 
and OS/2 when the exception that one has to handle is raised.  This is 
because on such systems the decommitted stack scheme relies upon all 
functions performing stack probes.  Stack probes happen in the function 
perilogue, at the beginning before the meat of the function begins 
execution, and it is during those probes that the exceptions will be 
raised, as guard pages and non-stack areas are referenced by the probing.

     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-perilogues.html#StackProbes

Specifically, what happens is that a (OS/2 or Win32, not C++) exception 
is raised when a new guard page cannot be set.  Microsoft KnowledgeBase 
article Q315937 shows how to catch such exceptions, and the small amount 
of cleanup that is necessary to handle the fact that the exception is 
raised partway through the stack growth process.  OS/2 has the same 
mechanism, and the exception to catch is the fairly straightforwardly 
named XCPT_UNABLE_TO_GROW_STACK .  (Notice that on OS/2 this exception 
is raised by code that is itself an exception handler, for the 
XCPT_GUARD_PAGE_VIOL exception.)

     
http://cyberkinetica.homeunix.net/os2tk45/cp2/851_L3_XCPT_GUARD_PAGE_VIOL.html

Again, these exceptions are raised as a result of actions taken in the 
function perilogue, not the function body proper.  You'll note from the 
function perilogues FGA page that there's a problem with some compilers 
that don't properly account for the calling parameters area; but, that 
poor quality compiler issue set aside, this means that (except for 
alloca() and variable-length arrays) one can be assured that one won't 
have to deal with this once a function's activation record has been 
fully pushed onto the stack by the perilogue.

As for the "gas gauge": That's a matter of comparing the current stack 
pointer with the stack bottom recorded in the Thread Information Block, 
code for most of which (obtaining the amount still remaining instead of 
the amount already used being a minor exercise for the reader) is on the 
quite appropriately named StackOverflow, in an answer to a question on 
this very subject.

     
http://stackoverflow.com/questions/1740888/determining-stack-space-with-visual-studio/1747249#1747249

Back to comp.os.os2.programmer.misc | Previous | Next — Next in thread | Find similar

Thread

Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
  Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
    Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
      Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
      Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
  Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000

csiph-web