This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12453] New: Broken thread local storage (TLS) initialization
- From: "Martin.vGagern at gmx dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sun, 30 Jan 2011 15:14:26 +0000
- Subject: [Bug libc/12453] New: Broken thread local storage (TLS) initialization
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12453
Summary: Broken thread local storage (TLS) initialization
Product: glibc
Version: 2.12
Status: NEW
Severity: critical
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: Martin.vGagern@gmx.net
Created attachment 5218
--> http://sourceware.org/bugzilla/attachment.cgi?id=5218
Script reproducing the issue
When dynamically loading a library along with several dependencies, calls to
_dl_add_to_slotinfo and _dl_update_slotinfo can become intermixed. As a
consequence, _dl_update_slotinfo will update the generation counter of the dtv
although not all of the slots belonging to that generation have been added.
Subsequent calls to _dl_add_to_slotinfo will add more slots to the same
generation, for which no storage will be allocated, as the dtv generation
checks will claim no work is necessary. This will lead to uninitialized dtv
entries and will likely cause a SIGSEGV when thread local variables are
accessed.
The attached script, when executed in an empty directory on a GNU/Linux x86_64
system, and probably under other circumstances as well, will demonstrate the
problem. It will print
./demo
&tbaz=(nil)
glibc-tls-bug.sh: line 75: 1752 Segmentation fault "$@"
where you see that the address of the thread local variable tbaz is NULL, and
the referencing that variable causes a segmentation fault.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.