<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>The stack pages must be touched in order.</div><div><br></div><div><br></div><div>It cannot be dynamically ordered in such a way that pages are skipped.</div><div>It is much easier to have a static order than worry about getting a dynamic order correct.</div><div><br></div><div><br></div><div>That is, sure, you can do some large subtract all at once,</div><div>but you must not skip around in the order the pages are touched.</div><div><br></div><div><br></div><div>You can defer the exception until the jmpbuf is touched,</div><div>and you can get away without touching any, but whatever you</div><div>touch, must be in order.</div><div><br></div><div><br></div><div>The solution is simple though -- actually call _alloca.</div><div>It gets it right.</div><div><br></div><div><br></div><div>Imagine this:</div><div><br></div><div>jmpbuf bufs[n];</div><div>while (1)</div><div> switch (srand() % n)</div><div> {</div><div> case 0: TRY ... break;</div><div> case 1: TRY ... break;</div><div> case 2: TRY ... break;</div><div> case 3: TRY ... break;</div><div> }</div><div>}</div><div><br></div><div><br></div><div>that wouldn't work properly w/o a bit of extra code.</div><div><br></div><div><br></div><div>On NT, if you write a function with more than a page of locals,</div><div>the start of the function calls chkstk, which is another name for alloca,</div><div>to be sure to touch the page(s).</div><div><br></div><div><br></div><div>Because, imagine you have a function with more than a page of locals,</div><div>that the first thing it does is call another function. The pushing of the</div><div>return address will touch the stack, but possibly skip a page.</div><div><br></div><div><br></div><div>If you just have lots of functions with less than a page of locals,</div><div>the pushing of return addresses to make further calls is what touches</div><div>the pages.</div><div><br></div><div><br></div><div>It is easy to see in the generated code.</div><div>We likely have a bug here in NT/x86 *forever*.</div><div>It is fixed in the C backend. :)</div><div>The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.</div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div><hr id="stopSpelling">Date: Sun, 19 Jul 2015 11:10:20 +0200<br>From: estellnb@elstel.org<br>To: jay.krell@cornell.edu; hendrik@topoi.pooq.com; m3devel@elegosoft.com<br>Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?<br><br>
<br>
<div class="ecxmoz-cite-prefix">Am 2015-07-19 um 10:56 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">
<div>Merely subtracting the stack pointer isn't correct on all
systems.</div>
<div>At least on NT, stack pages must be touched in order
without skipping any,</div>
<div>for stack overflow exceptions to work correctly.</div>
<div>There is a high water mark, so it isn't necessarily linear.</div>
</div>
</blockquote>
<br>
Would that mind if the stack exception was generated somewhat <br>
later when the jumpbuf actually becomes accessed?<br>
I would believe no.<br>
<br>
<blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
<div dir="ltr">
<div><br>
</div>
<div>NEWA: alloca is considered kind of dangerous, in that
failure</div>
<div>is difficult to recognize, or not portably recognizable and
handlable.</div>
</div>
</blockquote>
<br>
The same stack overflow exception can be generated by any <br>
procedure call so that I do not see why it should be that <br>
dangerous. In the overwhelming majority of cases this should<br>
be handled as gracefully as an extension of the heap on NEW:<br>
simply map a new memory page as long as there is enough<br>
free virtual address space.<br>
<br>
<br>
<blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
<div dir="ltr">
<div><br>
</div>
<div>If people can do the work/research/testing for recognizing
stack exhaustion</div>
<div>on a decent set of systems -- Linux, Solaris, FreeBSD,
OpenBSD, NetBSD, NT,</div>
<div>possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
traction in my mind.</div>
</div>
</blockquote>
As we are planning a new realease I would believe that your new <br>
alterations would become tested shortly.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></div> </div></body>
</html>