This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/12307] accessing thread local storage blocks forever when using dlopen


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]