使用dlopen()加载共享库出现错误

Question

使用dlopen()加载共享库出现错误

6

我正在开发一个程序，使用dlopen在CentOS上加载用户创建的插件。但是我遇到了一个问题，因为该插件依赖于其他共享库：

libplugin.so -> libservices.so -> libconfig.so

我们的程序首先将依赖项加载到内存中，从依赖树的叶子节点开始向上移动到插件（在这个示例中省略了错误检查）：

dlopen("/path_to_plugin/libconfig.so", RTLD_NOW | RTLD_GLOBAL)
dlopen("/path_to_plugin/libservices.so", RTLD_NOW | RTLD_GLOBAL)
dlopen("/path_to_plugin/libplugin.so", RTLD_NOW | RTLD_GLOBAL)

我们采用这种方法是为了使最终用户无需修改LD_LIBRARY_PATH以指向插件所在的目录。这种方法已经成功地应用于多个不同的插件。

最近我们收到了一个新的插件，但是这种方法无法使用。我们可以成功加载libconfig.so，但当我们尝试加载libservices.so时，会出现以下错误信息：

Exception libconfig.so: cannot open shared object file: No such file or directory

我知道库之间的符号依赖关系都得到了满足，因为当我将LD_LIBRARY_PATH设置为包含插件路径时，插件可以正确地加载和执行。

当我在程序上运行strace时，我可以看到系统正在执行dlopen手册中描述的libconfig.so搜索。因此，似乎由于某种原因，dlopen未检测到已经加载了libconfig.so。可能会导致这种行为的情况是什么？

- Blake Nelson

1

请使用例如 ltrace 进行检查，确保 libconfig.so 的 dlopen 被调用了两次，并且参数和路径完全相同。 - Basile Starynkevitch

顺便提一下，在strongswan项目中也存在不同类型插件的类似问题... https://wiki.strongswan.org/issues/538 - Pavel Šimerda

对我来说，最容易使用每个插件一个 *.so，并以项目名称为前缀存储在系统库目录中。这与 autotools 特别兼容，甚至可以从开发树运行。请参见 https://sourceware.org/git/?p=netresolve.git;a=blob;f=Makefile.am;h=4223162b82e539c1d9c623776962ac0654301c18;hb=HEAD#l78 - Pavel Šimerda

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Employed Russian · Accepted Answer

什么情况会导致这种行为？

当您调用dlopen("/path_to_plugin/libservices.so", ...)时，加载器会执行以下操作：

1. 打开给定路径，验证它是具有正确体系结构的适当ELF文件。 2. 读取该文件的动态部分。对于每个DT_NEEDED（这里是libconfig.so）， 3. 扫描已经打开的DSO列表，查找完全匹配项（在此处失败）， * 如果找到，则增加引用计数。 * 否则尝试在磁盘上查找所需的库。

由于步骤3对您而言失败了，因此可以非常肯定地说某些情况已经破坏了已经打开的DSO列表，或者有人在libconfig.so上调用了dlclose。

如果GDB info shared在第3步仍然列出libconfig.so，则是前者。如果没有，则是后者。

您可以通过查看GDB中的_r_debug->r_map元素并将其与GDB info shared输出进行比较来验证破坏。

该列表中的第一个条目将具有主执行文件、VDSO和直接链接的共享库（例如libc.so.6和libdl.so.2）。然后，您应该会看到libconfig.so的条目，除了它的l_name可能以某种方式被翻译。

如果确实是这种情况，您可以通过在dlopen("/path/to/libconfig.so",...)上设置断点来查找污损加载器列表的人，并验证此时r_map是否正确，然后在稍后被破坏的内存上设置监视点。

另一方面，如果您在其他地方遇到过dlclose问题，则只需在dlclose上设置断点即可快速找到问题。

更新：

“我很难弄清楚如何查看_r_debug->r_map的内容。”

有两种方法可以访问它：

Install debuginfo packages for your GLIBC. On Ubuntu, apt-get install libc6-dbg should do, or

Compile your program in such a way that the debug info for _r_debug is included in it. For example:

cat t.c
int main() { return 0; }

gcc -g t.c && gdb -q ./a.out
(gdb) start
Temporary breakpoint 1 at 0x4004e1: file t.c, line 1.
Starting program: /tmp/a.out

Temporary breakpoint 1, main () at t.c:1
1   int main() { return 0; }
(gdb) p _r_debug
$1 = 1    # The program does not reference _r_debug itself,
          # and debuginfo is not installed. This is probably what you see.

让我们来修复它:

cat t2.c
#include <link.h>

int main() { return _r_debug.r_version; }  // reference needed for debug info

gcc -g t2.c && gdb -q ./a.out
(gdb) start
Temporary breakpoint 1 at 0x400561: file t2.c, line 3.
Starting program: /tmp/a.out

Temporary breakpoint 1, main () at t2.c:3
3   int main() { return _r_debug.r_version; }
(gdb) p _r_debug
$1 = {r_version = 1, r_map = 0x7ffff7ffe1c8, r_brk = 140737351960640, r_state = RT_CONSISTENT, r_ldbase = 140737351884800}
(gdb) p _r_debug.r_map[0]
$2 = {l_addr = 0, l_name = 0x7ffff7df6c3d "", l_ld = 0x600e18, l_next = 0x7ffff7ffe758, l_prev = 0x0}