r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Sean Silva via cfe-commits]

On Fri, Aug 19, 2016 at 4:33 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> On Fri, Aug 19, 2016 at 03:30:42PM -0700, Richard Smith wrote:
> > It typically does; the default stack ulimit is likely tuned for "normal"
> > applications that are not expected (by an ISO standard) to cope with
> > recursing a thousand levels deep. If the system administrator really
> wants
> > to control the stack space for some stupid reason, they can set a hard
> > ulimit. If people actually do that, and then file bugs on clang crashing
> > (which they do today), we may want to resort to spawning a separate
> thread
> > with a higher ulimit if we detect the problem.
>
> Thread stacks by default are even smaller and for good reason.
>

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.

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?)

-- Sean Silva


> Especially on 32bit platforms, it would be unusable otherwise. To put
> this into perspective: if you need to support a recursion level of 1000
> and can't do that with a 4MB stack, it means you are using more than 4KB
> per recursion level. That's a very high stack use and certainly
> something that qualifies as the kind of abusive behavior the process
> limit is designed for in first place.
>
> > It *is* unreasonable to expect them to fiddle with stack ulimits to get
> the
> > compiler to accept programs that, say, use certain components of boost
> (and
> > fit within the standard's recommended limits).
>
> I fundamentally disagree with this statement. Effectively, this seems to
> me to be papering over excessive stack use and nothing else.
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160819/87b7b5d1/attachment.html>