This is the mail archive of the mailing list for the binutils 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]

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


I ran app with LD_DEBUG=bindings and found out that libC can't find a symbol:
10272: /media/EXT/work// 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.

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