[PATCH] D66361: Improve behavior in the case of stack exhaustion.

[Richard Smith via cfe-commits]

On Tue, 3 Sep 2019 at 17:59, Kamil Rytarowski via Phabricator via
cfe-commits <cfe-commits at lists.llvm.org> wrote:

> krytarowski added a comment.
>
> In D66361#1656037 <https://reviews.llvm.org/D66361#1656037>, @rsmith
> wrote:
>
> > In D66361#1655903 <https://reviews.llvm.org/D66361#1655903>,
> @krytarowski wrote:
> >
> > > This change broke on NetBSD.
> > >
> > >
> http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22003/steps/run%20unit%20tests/logs/FAIL%3A%20Clang%3A%3Astack-exhaustion.cpp
> >
> >
> > Test disabled for NetBSD in r370801. If you're interested in
> investigating why this isn't working there, feel free, but this is only a
> best-effort mitigation for the case where things have already gone wrong,
> so there are limits to how much effort it makes sense to resolve this.
> >
> > Does NetBSD set a hard stack rlimit of less than 8MB by any chance?
>
>
> The stack rlimit is restricted by default to 4MB. The maximum at least on
> amd64 is 128MB... but if someone really needs it, it could by bypassed with
> more stacks.
>
>   $ ulimit -a
>   time(cpu-seconds)    unlimited
>   file(blocks)         unlimited
>   coredump(blocks)     unlimited
>   data(kbytes)         262144
>   stack(kbytes)        4096
>   lockedmem(kbytes)    10847213
>   memory(kbytes)       32541640
>   nofiles(descriptors) 1024
>   processes            1024
>   threads              1024
>   vmemory(kbytes)      unlimited
>   sbsize(bytes)        unlimited
>
> Should the limit by raised by default in the system?
>

Clang expects 8MB stacks. When possible (if CLANG_HAVE_RLIMITS is enabled
at configure-time) it will increase the soft stack rlimit to 8MB if it can.

It could be that that's failing here, either because CLANG_HAVE_RLIMITS is
configured as 0, or because the hard stack limit is set below 8MB, or maybe
because this kernel doesn't apply new stack limits that are set after a
thread begins running. In the former case, there's not much we can do;
without a working getrlimit, we can't guess how much stack is even
available. In the latter cases, we could ask the system what the actual
limit is, and apply our stack overflow mitigation when we reach that
instead of when we reach (nearly) 8MB.

Can you find out which of these (if any) is the case?


> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D66361/new/
>
> https://reviews.llvm.org/D66361
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> https://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/20190906/7fe3bb3f/attachment.html>