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

[Richard Smith via cfe-commits]

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

> On Fri, Aug 19, 2016 at 01:03:51PM -0700, Richard Smith wrote:
> > On Fri, Aug 19, 2016 at 12:58 PM, Joerg Sonnenberger via cfe-commits <
> > cfe-commits at lists.llvm.org> wrote:
> >
> > > On Thu, Aug 18, 2016 at 11:33:49AM -0700, Richard Smith wrote:
> > > > On Wed, Aug 17, 2016 at 6:35 AM, Joerg Sonnenberger via cfe-commits <
> > > > cfe-commits at lists.llvm.org> wrote:
> > > >
> > > > > On Wed, Aug 17, 2016 at 01:05:08AM -0000, Richard Smith via
> cfe-commits
> > > > > wrote:
> > > > > > Author: rsmith
> > > > > > Date: Tue Aug 16 20:05:07 2016
> > > > > > New Revision: 278882
> > > > > >
> > > > > > URL: http://llvm.org/viewvc/llvm-project?rev=278882&view=rev
> > > > > > Log:
> > > > > > If possible, set the stack rlimit to at least 8MiB on cc1
> startup,
> > > and
> > > > > work
> > > > > > around a Linux kernel bug where the actual amount of available
> stack
> > > may
> > > > > be a
> > > > > > *lot* lower than the rlimit.
> > > > >
> > > > > Can you please restrict this to Linux? I'm quite opposed to
> overriding
> > > > > system default limits, they exist for a reason.
> > > >
> > > >
> > > > No, that wouldn't make any sense. It's not up to the operating
> system how
> > > > an application decides to allocate memory (on the heap versus on the
> > > > stack), and Clang's stack usage isn't going to be significantly
> lower on
> > > > other kernels. If some BSD kernel's VM is unable to cope with this,
> we
> > > > could spawn a thread with a suitable amount of stack space instead.
> > >
> > > This is not about kernel bugs. It is about POLA -- programs are not
> > > supposed to alter process limits. If GCC does it, it is a GCC bug.
> > > That's no reason to introduce the same bug here. Using excessive stack
> > > space due to deep recursion might be a QoI issue, but it is
> > > fundamentally no different from any other out of memory condition.
> Those
> > > kill clang just as easily.
> >
> >
> > Hitting this limit does not imply that memory was exhausted, it instead
> > means the OS killed a process that was functioning just fine, for no good
> > reason.
>
> You are allocating too much stack space.


Whether we choose to put data on the heap or stack is not up to you or the
operating system.

There is no difference to heap
> allocations which are bound by different flags. It is just a different
> allocation mechanism. Even hitting a 4MB stack space limit on 64bit
> platforms takes quite a bit -- not even boost does that by default. As
> such, I hardly find it normal.


It's not normal; that's why we're explicitly opting into it here, using the
mechanism that POSIX provides to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160819/12c3b9e8/attachment.html>