This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/12307] accessing thread local storage blocks forever when using dlopen
- From: "maxim.yegorushkin at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 13 Oct 2013 11:42:11 +0000
- Subject: [Bug dynamic-link/12307] accessing thread local storage blocks forever when using dlopen
- Auto-submitted: auto-generated
- References: <bug-12307-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=12307
Maxim Yegorushkin <maxim.yegorushkin at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |---
--- Comment #2 from Maxim Yegorushkin <maxim.yegorushkin at gmail dot com> ---
A C++ constructor is used here instead of creating a function marked with gcc
constructor attribute. See
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Function-Attributes.html#index-g_t_0040code_007bdestructor_007d-function-attribute-2594
In either case (C++ constructor and gcc constructor function) that code gets
executed when a shared library is loaded, which may be before main() or while
in main(). As far as I am aware, there are no documented restrictions on which
functions can not be called in either (like there are restrictions for what can
be called from a signal handler).
Dynamic linking is designed to be transparent and I expect the same result in
the case when ld.so loads the .so before main() is executed as well as when the
program explicitly loads the .so from main().
Robert Y. Liu reports that this code works as expected with glibc-2.5, but not
with glibc-2.12, so it appears that a regression crippled in somewhere between
these two versions. I just checked it with Fedora 18 and glibc-2.16 and it is
still broken.
I don't think "stupid" is valid justification for closing this technical issue.
--
You are receiving this mail because:
You are on the CC list for the bug.