This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/16592] crash in startup
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 19 Feb 2014 05:29:00 +0000
- Subject: [Bug dynamic-link/16592] crash in startup
- Auto-submitted: auto-generated
- References: <bug-16592-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16592
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #11 from Carlos O'Donell <carlos at redhat dot com> ---
(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.