From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21129 invoked by alias); 13 Oct 2013 11:42:17 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 21064 invoked by uid 48); 13 Oct 2013 11:42:12 -0000 From: "maxim.yegorushkin at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/12307] accessing thread local storage blocks forever when using dlopen Date: Sun, 13 Oct 2013 11:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.12 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: maxim.yegorushkin at gmail dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-10/txt/msg00137.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=12307 Maxim Yegorushkin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #2 from Maxim Yegorushkin --- 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.