[Bug 1757517]

[D-i-j]

PTHREAD_STACK_MIN/RLIMIT_STACK/minstack computation is now in
sysdeps/nptl/pthread_early_init.h . I think there is not much change
from 2012.


I agree that the current behavior is not ideal. musl has a heuristic to address the problem (https://git.musl-libc.org/cgit/musl/commit/?id=d5142642b8e6c45449158efdb8f8e87af4dafde8):

> the new strategy pthread_create now uses is to only put TLS on the
> application-provided stack if TLS is smaller than 1/8 of the stack
> size or 2k, whichever is smaller. this ensures that the application
> always has "close enough" to what it requested, and the threshold is
> chosen heuristically to make sure "sane" amounts of TLS still end up
> in the application-provided stack.
> 
> if TLS does not fit the above criteria, pthread_create uses mmap to
> obtain space for TLS, but still uses the application-provided stack
> for actual call frame stack. this is to avoid wasting memory, and for
> the sake of supporting ugly hacks like garbage collection based on
> assumptions that the implementation will use the provided stack range.

Here is a one-liner for people to investigate large p_memsz(PT_TLS)

   for i in /usr/bin/*(.) /usr/lib/x86_64-linux-gnu/*; do readelf -Wl $i
NN | awk '$1=="TLS" && strtonum($6) > 64 {printf "%d\t", strtonum($6);
exit(1)}' || echo $i; done

(Adjust paths and `> 64` as needed.)

It seems that chrome has smaller PT_TLS now. On my machine there are
DSOs with large p_memsz(PT_TLS):

libtsan.so.2.0.0 has a 785760 byte p_memsz(PT_TLS) due to a large vector clock (TSAN runtime v3 has a much smaller one).
liblsan.so.0.0.0 (56240)
libglog.so.0.6.0 (30457)
libmetis.so.5.1.0 (28920)
...

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1757517

Title:
  An unused thread-local memory allocation can cause library calls to
  segfault.

Status in GLibC:
  Confirmed
Status in glibc package in Ubuntu:
  New

Bug description:
  I've discovered that adding "static __thread anything[8 * 1048576]" to
  otherwise working programs will cause them to segfault.  I've attached
  a short example that demonstrates the problem.

  Compile the attached program like this:  gcc -o test test.c -lpthread
  -lasound

  When running it, it will display this:

  Spawning thread...
  Joining thread...
  I'm a thread!
  Segmentation fault

  Unfortunately I haven't been able to figure out how to reproduce it
  without using libasound, except that I can use libjack to trigger it
  instead, but since that makes two independent libraries that have this
  problem, I assume it is caused by something common between them, like
  pthreads, GCC, or the Linux kernel.

  FWIW, with the Jack version of the bug, I've seen it do two things.
  With a larger allocation it displays messages about being unable to
  create threads before failing to connect to its server.  With a
  smaller allocation, it connects to its server, but then segfaults
  later in a different call to libjack.

  In all cases, merely removing the "static __thread anything[8 *
  1048576]" from the program causes the libraries to work correctly.
  Since the variable is never accessed by anything, adding it to the
  programs should have no effect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1757517/+subscriptions