On Fri, Aug 19, 2016 at 12:58 PM, Joerg Sonnenberger via cfe-commits < cfe-commits@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@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. As you say, this limit exists for a reason -- and the reason is to catch programs that are recursing infinitely or using an unexpected amount of stack space. In Clang's case, using a lot of stack is not unexpected and does not suggest infinite recursion. So the appropriate thing to do is to relax or otherwise avoid the arbitrary and harmful limit.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
