public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/16133] New: Access to __thread variable may call malloc
@ 2013-11-07  0:52 ppluzhnikov at google dot com
  2013-11-23 23:42 ` [Bug dynamic-link/16133] " carlos at redhat dot com
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: ppluzhnikov at google dot com @ 2013-11-07  0:52 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-13  9:34 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-07  0:52 [Bug dynamic-link/16133] New: Access to __thread variable may call malloc ppluzhnikov at google dot com
2013-11-23 23:42 ` [Bug dynamic-link/16133] " carlos at redhat dot com
2014-01-12  0:57 ` ppluzhnikov at google dot com
2014-01-12  1:00 ` cvs-commit at gcc dot gnu.org
2014-02-05  3:32 ` cvs-commit at gcc dot gnu.org
2014-02-05 11:24 ` cvs-commit at gcc dot gnu.org
2014-02-05 11:24 ` cvs-commit at gcc dot gnu.org
2014-02-05 14:46 ` ppluzhnikov at google dot com
2014-02-05 14:46 ` ppluzhnikov at google dot com
2014-02-05 22:47 ` cvs-commit at gcc dot gnu.org
2014-02-05 22:47 ` cvs-commit at gcc dot gnu.org
2014-06-13  9:34 ` fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).