This is the mail archive of the
mailing list for the glibc project.
PLT entry not initialized when loading a library, but called nevertheless
- From: Sergey Prokhorenko <sergey dot prokhorenko at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Tue, 11 Dec 2012 20:23:22 +0200
- Subject: PLT entry not initialized when loading a library, but called nevertheless
Sorry to bother if that's not an appropriate mailing list but I'm not
really sure where to post this question about dlopen and shared
I found a strange bug when loading a nested shared library. Say I have
libA that depends on libB that depends on libC. A/B I compile myself
and C is precompiled in binary form by 3rd party (not that it's really
important - jfyi).
When I start the app it crashes with SIGSEGV
after__static_initialization_and_destruction_0in libC, while calling
MyFunc@plt from my "common to all" library libX. The stack is as
... (dl_XXX activity)
I ran app with LD_DEBUG=bindings and found out that libC can't find a symbol:
10272: /media/EXT/work//libC.so: error: symbol lookup error: undefined
symbol: omp_set_num_threads (fatal)
which is a 3rd-party libC problem (I know the reason and it is fixed
now) BUT after this error, LD_DEBUG shows that symbols are continued
to be resolved now inside libA while completely skipping the rest of
libC and all of the libB ones. So that when it comes to calling static
init of libC half of PLT entries are unresolved, thus the crash. Or
that's how I see it.
In optimized version of my app it is able to resolve that symbol (to
libgomp). In that version I see that without unresolved omp_ error it
completes libC bindings then continues with libB bindings and then
with libA bindings. This is to compare to the non-optimized version
(as described above) where it does not complete libC bindings and does
not do libB.
So my question is (if you allow as I'm not really big expert in this
are) - can it be that this is dlopen/ld bug and am I in the correct
mail list after all? I think now that it is not ld bug, it seems that
ld stops loading but dl continues despite the error.
The environment is Ubuntu 12.04 x86_64 with latest updates, app is
i386 though, compiled with stock gcc 4.6. I am not sure where and how
libC was compiled, but since everything worked fine when compiling on
Ubuntu 11.10 I may suspect that libC was also compiled here, and the
bug appeared when we upgraded to Ubuntu 12.04 and its gcc/ld. The bug
disappeared when I get updated libC version built on 12.04 from 3rd
party. Still I wonder why it is possible to leave shared library (even
built by some other tool) in a half-initialized state and are my
conclusions above correct.