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/14577] dlopen does not unload failed module - second dlopen succeeds


https://sourceware.org/bugzilla/show_bug.cgi?id=14577

cnewbold at mathworks dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cnewbold at mathworks dot com

--- Comment #4 from cnewbold at mathworks dot com ---
We've tracked down an issue with very similar symptoms that is likely related
to the issue documented here. In our case, the library which cannot load and
which then gets stuck in a half-loaded state does not have the NODELETE flag
set but does contain an STB_GNU_UNIQUE symbol.

The issue only occurs when a library (1) contains an STB_GNU_UNIQUE symbol that
has not yet been loaded/resolved from some other library; and (2) fails to load
for some reason, such as with RTLD_NOW and unresolved references. Under these
conditions, ld.so loads and resolves the STB_GNU_UNIQUE symbol as the libray is
loaded and notes that dependency. However, when the load ultimately fails with
an unresolved symbol, the linkage to the STB_GNU_UNIQUE symbol is not
undone--which then prevents the cleanup from the failed load from fully
unloading the library.

I've attached a test case which provokes this failure.

The wrinkle when STB_GNU_UNIQUE is involved is that if a definition of the same
STB_GNU_UNIQUE symbol is already present in the process, the load will fail and
will properly clean up the partially-loaded library.

The test case I've attached illustrates this by comparing the behavior of two
different load orders:

    (1) h = dlopen("bad.so", RTLD_NOW | RTLD_GLOBAL); /* fails -- unresolved */
    (2) h = dlopen("bad.so", RTLD_NOW | RTLD_GLOBAL | RTLD_NOLOAD); /*
succeeds?!? */
    (3) if (h) dlclose(h); /* assertion from within dlclose! */

vs.

    (1) h_good = dlopen("good.so", RTLD_NOW | RTLD_GLOBAL); /* succeeds */
    (2) h_bad = dlopen("bad.so", RTLD_NOW | RTLD_GLOBAL); /* fails --
unresolved */
    (3) h_bad = dlopen("bad.so", RTLD_NOW | RTLD_GLOBAL | RTLD_NOLOAD); /*
fails again */

Where both bad.so and good.so contain instances of the same STB_GNU_UNIQUE
symbol.

I'm not sure whether this warrants a separate bug report or not.

-- 
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]