This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
PLT entry not initialized when loading a library, but called nevertheless
- From: Sergey Prokhorenko <sergey dot prokhorenko at gmail dot com>
- To: binutils at sourceware dot org
- Date: Tue, 11 Dec 2012 17:15:39 +0300
- Subject: PLT entry not initialized when loading a library, but called nevertheless
Hello.
Sorry to bother if that's not an appropriate mailing list but I'm not
really sure where to postthis question about ld and shared library loading.
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 but).
When I start the appit 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 follows:
0x12345
__static_initialization_and_destruction_0
...
dlopen("libA")
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 probably the 3rd-party libC problemBUT after that, it continues
to resolve symbols inside libA while completely skipping the rest of
libC and all of the libB ones. So that when it comes to calling static
initof libC then half of PLT entries are unresolved, thus the crash. Or
that's how I see it.
I have built anoptimized version of my app and there for some reason it
is able to resolve that symbol (to libgomp). Also I see there 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 bugand am I in the correct mail list
after all?
The environment is Ubuntu 12.04 x86_64 with latest updates, app is i386
though, compiled with stock gcc 4.6. Iam not sure where and how libC was
compiled.Since everything worked fine when compilingon 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 was gone when I get
updated libC version built on 12.04 from3rd party. Still I wonder why
itis possible to leave shared library (even built by some other tool) in
a half-initialized state andare my conclusions above correct.
Thanks, Sergey.