From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11470 invoked by alias); 19 Feb 2014 05:29:37 -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 11435 invoked by uid 48); 19 Feb 2014 05:29:33 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/16592] crash in startup Date: Wed, 19 Feb 2014 05:29: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.18 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00658.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D16592 --- Comment #12 from Carlos O'Donell --- (In reply to Stefan Seefeld from comment #7) > On 02/16/2014 11:03 PM, carlos at redhat dot com wrote: >=20 > > Does the audit library use TLS? >=20 > One of its dependencies probably does, yes. >=20 > Stefan I know of one bug which is not yet fixed upstream where an LD_AUDIT library that uses TLS can cause a segfault. I have the patch in my tree and should = push it out shortly. Do you have a way to test a patch? Can you rebuild your dis= tro glibc with a patch? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-21680-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Feb 19 05:29:08 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 11042 invoked by alias); 19 Feb 2014 05:29:07 -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 Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 11006 invoked by uid 48); 19 Feb 2014 05:29:03 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/16592] crash in startup Date: Wed, 19 Feb 2014 05:29: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.18 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: UNCONFIRMED 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 everconfirmed 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: 2014-02/txt/msg00657.txt.bz2 Content-length: 2291 https://sourceware.org/bugzilla/show_bug.cgi?id=16592 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #11 from Carlos O'Donell --- (In reply to Stefan Seefeld from comment #8) > I have managed to isolate the problem to a library constructor (function > marked as __attribute__((constructor)) ) causing the crash. > > What I don't understand is why this constructor fails in this situation (of > being part of an audit library), when it doesn't fail during normal linking > & loading. > > Shouldn't the loader take care of initializing the libraries in proper order > (as determined by symbol dependency analysis) ? Or is there in fact no > guarantee of order of initialization, and the library was just lucky enough > to always be initialized "late enough" until I started using it as part of > an auditor ? Multiple constructors in one library run in the order in which they are declared and consequently seen by the static linker and added to the .ctors section. The same applies for constructors for static objects in that the order of declaration is important. Inter constructor ordering can be modified by using a priority e.g. __attribute__((constructor(N))). The constructor ordering between libraries is specified by a breadth first search of DT_NEEDED entries. This ensures required libraries are initialized first before they are used. Symbol dependencies are not used at runtime to determine the constructor ordering. If you have a circular dependency then no order is guaranteed for the portion of the graph that has the circular dependency. We should provide some ld.so tooling to help find circular dependencies, detect them, and diagnose them, but we don't. Patches welcome. Is it possible you have a circular dependency? Can you look into that please? The test case you provided does not crash for me on Fedora 19 which is glibc-2.17 based. We really need a self-contained reproducible test case. -- You are receiving this mail because: You are on the CC list for the bug.