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

Chandler Carruth via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 19 17:45:59 PDT 2016


I feel like this thread has two very unrelated concerns and it might be
useful to separate them.

1) Should an application be changing the stack limit, or should the system
be able to enforce this?

Fortunately, there are two limits. One an application is allowed to change,
one it isn't. It seems like the mechanism has been provided for system
administrators to impose firm limits and neither Clang nor another
application will perturb them. I don't see any reason to preclude an
application from changing the one it is explicitly permitted to change.
That seems to be WAI from a permissions and ACL model.


2) Should Clang be using the stack to allocate significant portions of its
memory, or should it be assiduously keeping allocations on the heap and
removing recursive algorithms?

I actually think this is the crux of the issue, and #1 is largely coming up
as a proxy for "Clang should use less stack space".

However, I'll point out that this commit does not change how much stack
space Clang uses. It just changes the nature of errors that occur to make
the experience of today's Clang more friendly for users. So this commit
seems like a fine thing even if we decide that Clang should work to lower
this number over time and reduce what it sets it to. In fact, if you want
to reduce Clang's stack usage, you almost certainly want it to explicitly
set a limit so that we consistently hit errors when bugs creep into Clang.

Past that, while I think Clang's current allocation and recursion pattern
is fine, I don't actually have a terribly strong opinion. But it seems odd
to suddenly want to make a dramatic change in the design of Clang now... It
doesn't seem like this was an accidental or unconsidered design decision.

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.
> 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/20160820/6003dba4/attachment.html>


More information about the cfe-commits mailing list