Thread stack size issue related to glibc TLS bug

[Martin Buchholz]

On Mon, May 27, 2019 at 2:07 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Martin Buchholz:
>
> > Very big picture - if we want to banish stack overflows forever, we would
> > need to migrate the industry to split runtime stacks, which would add a
> bit
> > of runtime overhead to every native function call.  No one is heroic
> enough
> > to make progress towards that.  Maybe developers of new OSes need to read
> > this thread?
>
> For an infinite recursion, you would still get an OutOfMemoryError, only
> much later and potentially after taking down the desktop environment.
>

Of course there is a problem with resource exhaustion.
The idea is to have fewer different limits for the same sort of resource
(here, memory).
Conceptually, I don't see any difference between allocating stack space and
allocating native heap space (via malloc).
Both sorts of memory could come out of the same pool.
We need to protect against global resource exhaustion, but I'd like to see
all the limits at the process level.

We have some existing code that converts recursive call chains into an
explicit data structure on the java heap to avoid StackOverflowError.


> Furthermore, if the thread stack is not committed memory, then
> try-finally blocks will not work reliably because any function call may
> attempt to enlarge the stack and fail to do so.
>

We already have a problem with try-finally failing when stack space is
exhausted.
We have a kludgy unreliable workaround via @ReservedStackAccess.


> > One strong hint is that glibc uses that when it needs to create its own
> > helper thread with minimal stack.
> > But why-oh-why not expose that for use by others?  Other software like
> Java
> > or Rust has the same needs!
>
> Creating a stack with __pthread_get_minstack() bytes doesn't mean the
> thread can do anything useful.  For example, the thread will not on a
> kernel with a vDSO compiled with -fstack-check.  You can can't call
> (f)printf on a file stream which is unbuffered.  The thread may not be
> able to receive any signals whatsoever.  And so on.  That's why it's not
> a public interface.
>

Well, of course a thread stack allocator can't
expect __pthread_get_minstack() by itself to be sufficient.
Any application specific requirements need to be added.
glibc  itself adds 4 * PTHREAD_STACK_MIN.
Java would add user-specified stack size (for java frames) plus any other
JVM overhead like "red zone" pages.
Again, I see glibc's  own needs to be very similar to the JVM's needs.


> I suggested to use this interface only as a workaround for the TLS
> allocation issue.
>
> Thanks,
> Florian
>