Home Original page

PLT entry not initialized when loading a library, but called nevertheless

Igor Pashev pashev.igor@gmail.com
Tue Dec 11 15:41:00 GMT 2012 
11.12.2012 18:15, Sergey Prokhorenko пишет:
> 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.

This is hardly a binutils bug, especially on linux/x86_64 :-)


I can guess, that libC is not linked to libgomp (from GCC) or whichever
OpenMP library being used.
More information about the Binutils mailing list