<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 19, 2016 at 4:33 PM, Joerg Sonnenberger via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Fri, Aug 19, 2016 at 03:30:42PM -0700, Richard Smith wrote:<br>
> It typically does; the default stack ulimit is likely tuned for "normal"<br>
> applications that are not expected (by an ISO standard) to cope with<br>
> recursing a thousand levels deep. If the system administrator really wants<br>
> to control the stack space for some stupid reason, they can set a hard<br>
> ulimit. If people actually do that, and then file bugs on clang crashing<br>
> (which they do today), we may want to resort to spawning a separate thread<br>
> with a higher ulimit if we detect the problem.<br>
<br>
</span>Thread stacks by default are even smaller and for good reason.<br></blockquote><div><br></div><div>Could you elaborate on this a bit more? I don't understand how a process adjusting its own soft stack limit is "abusive" in any way.</div><div><br></div><div>Richard's patch is in cc1_main.cpp so it is at the top-level entry point of the program, so we already know how many threads we intend to spawn etc. so the issue of VA exhaustion on 32-bit seems moot. (libc might spawn threads internally though, which could be an issue; Richard mentioned a workaround though which is spawning the entire compilation onto a separate thread with sufficient stack; would that work for you?)</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Especially on 32bit platforms, it would be unusable otherwise. To put<br>
this into perspective: if you need to support a recursion level of 1000<br>
and can't do that with a 4MB stack, it means you are using more than 4KB<br>
per recursion level. That's a very high stack use and certainly<br>
something that qualifies as the kind of abusive behavior the process<br>
limit is designed for in first place.<br>
<span class=""><br>
> It *is* unreasonable to expect them to fiddle with stack ulimits to get the<br>
> compiler to accept programs that, say, use certain components of boost (and<br>
> fit within the standard's recommended limits).<br>
<br>
</span>I fundamentally disagree with this statement. Effectively, this seems to<br>
me to be papering over excessive stack use and nothing else.<br>
<div class=""><div class="h5"><br>
Joerg<br>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>