[Bug dynamic-link/16133] New: Access to __thread variable may call malloc

["ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16133

            Bug ID: 16133
           Summary: Access to __thread variable may call malloc
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: ppluzhnikov at google dot com

Discussion thread:
https://sourceware.org/ml/libc-alpha/2012-06/msg00335.html

ppluzhnikov>

When writing CPU or heap profilers, one frequently desires to have fast
and async-signal-safe access to thread-local variables.

The __thread variables generally fit the bill (at least on Linux/x86),
when the variable is in the main executable, or in a directly-linked DSO.

But when the DSO is dlopen()ed (and does not use initial-exec TLS model),
the first access to TLS variable from a given thread triggers a call to
malloc (with the following stack):

#0  0x00007f10ea319c97 in malloc () from /lib64/libc.so.6
#1  0x00007f10eac75b6c in tls_get_addr_tail () from /lib64/ld-linux-x86-64.so.2
#2  0x00007f10eac76760 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
#3  ... profiler accessing __thread variable ...
#4 <signal handler>

iant>
We are currently in an unpleasant situation where it is very easy and
natural to use TLS variables--you just refer to them by name--and using
them in a signal handler almost always works just fine.  Except that in
some highly specific but not completely implausible circumstances it
crashes incomprehensibly.  This is not a good thing, it's a lurking time
bomb.



Proposed patch:
http://www.sourceware.org/ml/libc-alpha/2013-10/msg00128.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.