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/16592] crash in startup


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.


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