调用@plt函数时，在dlopen / static init上共享库SIGSEGV

 

我的应用程序使用静态初始化代码构建了一个库。 所有其他库都是这样做的，并且之前加载得很好，但是当从另一个库调用函数时，它会死亡。 这是这样的： 

0x12311 <-- bad address
_static_initialization_0 <-- function call
....
dlopen

现在，反汇编中的函数调用看起来像 

call _Z6MyFuncRA37_Kc@plt

然而，这个呼叫结束了呼叫无效地址0x12311，即PLT条目得到错误的地址。

问题很可能是所讨论的库是第三方库，即使它依赖于其他库也是以二进制预构建的形式出现的。 上周我们进行了大量优化，并更改了很多头文件等等。 PLT错误的函数MyFunc位于我们的（另一个）库中，它获得了大量的优化更改。

这怎么可能？ 确切的问题是：

  • 导致PLT不匹配的机制是什么？
  • 有没有一种方法可以解决它，而无需触及预编译的库 - 可选，因为我可以得到重建版本，但我仍然好奇它为什么崩溃

    • 此外，使用-O2优化编译时，同样的应用程序工作正常，这就是我所说的奇怪（二进制库在这两种情况下都是相同的）。

    PS的Ubuntu的12.04 x86_64，但应用程序是I386。

    更新：在检查LD_DEBUG的注释（由于某种原因删除）中的建议是好的，在LD_DEBUG = bindings中，我在“崩溃”版本的应用程序中看到了这一点： 

     10272:  /media/EXT/work/build32/bin/libMyLib.so: error: 
    symbol lookup error: undefined symbol: omp_set_num_threads (fatal)

    然后它停止绑定libMyLib.so符号，而在非失败版本中，它保持绑定其他符号。 但我不明白为什么它会继续执行并尝试加载父库。 其实这个计划如下： 

    libA -> libB -> libMyLib

    libMyLib失败（如上面LD_DEBUG输出所示），所以它跳过它，并且libB完全（！）并继续绑定libA符号。 非失败版本完全加载libMyLib符号，然后继续使用libB符号，然后使用libA符号。

    坦率地说，它看起来像ld bug。

    至于为什么优化版本能够工作，我认为omp_方法并不是真的需要，并且通过链接器优化被抛出，因此它不会在运行时找到它。

    以下是我在LD_DEBUG =所有日志中看到的未找到libC的omp_符号之后的内容： 

    19225: symbol=omp_set_num_threads; lookup in file=/usr/lib/i386-linux-gnu/libXdmcp.so.6 [0]
19225: /media/EXT/Work/libC.so: error: symbol lookup error: undefined symbol: omp_set_num_threads (fatal)
19225:
19225: file=/media/EXT/libA.so [0]; destroying link map
19225:
19225: file=/media/EXT/libA.so [0]; dynamically loaded by /media/EXT/libX.so [0]
19225: file=/media/EXT/libA.so [0]; generating link map
19225: dynamic: 0xf2fdb764 base: 0xf2f81000 size: 0x00064a28
19225: entry: 0xf2f8ffd0 phdr: 0xf2f81034 phnum: 7
19225:
19225: checking for version `GCC_3.0' in file /lib/i386-linux-gnu/libgcc_s.so.1 [0] required by file /media/EXT/libA.so [0]
... few more checking
19225: object=/media/EXT/libA.so [0]
19225: scope 0: bin/mainapp /lib/i386-linux-gnu/libpthread.so.0 /media/EXT/libX.so ...
19225: scope 1:...
19225:
19225:
19225: relocation processing: /media/EXT/libA.so
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=bin/mainapp [0]
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/lib/i386-linux-gnu/libpthread.so.0 [0]
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/media/EXT/libX.so [0]
19225: binding file /media/EXT/libA.so [0] to /media/EXT/libX.so [0]: normal symbol `_ZTVN10__cxxabiv117__class_type_infoE'

... here it continues to bind libA symbols, and after finishing that

19225:
19225:
19225: calling init: /media/EXT/libC.so
19225:

    它会为未初始化的libC.so模块调用init。

    （只需提及libX.so是调用dlopen的基本模块，也包含所有其他库使用的基本方法。）

    在销毁libA的链接映射后，日志显示它再次生成，我不明白装载器是否继续加载libA，或者这次从头开始，而不打扰libB / libC。 那么，在任何情况下，它都会忽略libB / libC，直到调用libC的init为止。

    omp_set_num_threads与GCC内部的OpenMP支持相关。

    您可能应该在编译和链接时将-fopenmp标志传递给gcc（即使您只是在使用OpenMP的库中使用dlopen ）。

    也许原来的图书馆提供者忘记了。

    （OpenMP正在改变编译过程的整个行为）

    链接地址: http://www.djcxy.com/p/60529.html

    上一篇: Shared library SIGSEGV on dlopen / static init when calling @plt function

    下一篇: C++ Why does this specific situation cause a symbol linking error?