Thread stack size issue related to glibc TLS bug

[Florian Weimer]

* 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.

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.

> 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.

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

Thanks,
Florian