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

Posted 2023-02-22

【中文标题】调用@plt函数时在dlopen / static init上共享库SIGSEGV

【英文标题】：Shared library SIGSEGV on dlopen / static init when calling @plt function

【发布时间】：2012-12-11 09:35:32

【问题描述】：

我的应用 dlopens 带有静态初始化代码的库。所有其他库都做同样的事情并且之前加载得很好，但是当从另一个库调用函数时，这个库死了。这类似于：

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

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

call _Z6MyFuncRA37_Kc@plt

然而，这个调用最终调用了无效地址 0x12311，即 PLT 条目获得了错误的地址。

问题很可能是有问题的库是第 3 方库，即，即使它依赖于其他库，它也以二进制预构建形式出现。上周我们做了很大的优化，改变了很多标题等等。 PLT 错误的函数 MyFunc 位于我们的（另一个）库中，该库进行了大量优化更改。

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

导致PLT不匹配的机制是什么 有没有办法在不触及预编译库的情况下修复它 - 可选，因为我可以获得重建版本，但我仍然很好奇它为什么会崩溃

此外，同一个应用程序在使用 -O2 优化编译时运行良好，这就是我所说的奇怪（二进制库在两种情况下都是相同的）。

附： ubuntu 12.04 x86_64 但应用是 i386。

更新：在 cmets（由于某种原因已删除）中检查 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=all 日志中看到的 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的链接映射后，日志显示它再次生成，我只是不明白loader是继续加载libA还是从头开始而不关心libB / libC。好吧，在任何情况下它都会忽略 libB/libC，直到为 libC 调用 init。

【问题讨论】：

使用nm -C -D 对名称进行解密。

我为此使用了 c++filt，但实际上我知道该函数及其所在位置。

【参考方案1】：

omp_set_num_threads 与 GCC 内部的 OpenMP support 相关。

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

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

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

【讨论】：

是的，但这是一个不同的问题。

不，我认为你的应用程序应该使用 -fopenmp 构建，只要它是 dlopen 使用 OpenMP 的库。

当然，但这不是问题所在（正如我提到的，我已经得到了重建版本），我试图找出为什么会发生 PLT 问题，即我不认为在未设置所有 PLT 的情况下初始化库是可以的。