On Fri, Aug 19, 2016 at 4:33 PM, Joerg Sonnenberger via cfe-commits < cfe-commits@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
