Thread stack size issue related to glibc TLS bug
martinrb at google.com
Sat May 25 19:27:55 UTC 2019
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
Today, linux kernels run with a variety of libc implementations, so
attempts to use a private glibc symbol might end up looking just like
trying to use a public one, using dlsym at runtime.
It seems reasonable to switch from _dl_get_tls_static_info
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!
/* The helper thread needs only very little resources. */
(void) pthread_attr_setstacksize (&attr,
+ 4 * PTHREAD_STACK_MIN);
More information about the core-libs-dev