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

Question

我正在开发一个在 CentOS 上使用 dlopen 加载用户创建的插件的程序。我遇到了一个插件问题，该插件依赖于也具有依赖性的共享库：

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 时，我可以看到系统正在搜索 libconfig.so，如 dlopen 手册页中所述。因此，出于某种原因，dlopen 似乎没有检测到 libconfig.so 已经加载。什么情况会导致这种行为？

Answer 1

What conditions could cause this behavior?

当您调用 dlopen("/path_to_plugin/libservices.so", ...) 时，加载程序会这样做：

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

由于第 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 上设置断点就可以很快找到问题所在。

更新：

I'm having a difficult time figuring out how to see the contents of _r_debug->r_map

有两种方法可以访问它：

为您的 GLIBC 安装调试信息包。在 Ubuntu 上，apt-get install libc6-dbg 应该可以，或者

以包含 _r_debug 的调试信息的方式编译您的程序。例如：

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    # 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
 = {r_version = 1, r_map = 0x7ffff7ffe1c8, r_brk = 140737351960640, r_state = RT_CONSISTENT, r_ldbase = 140737351884800}
(gdb) p _r_debug.r_map[0]
 = {l_addr = 0, l_name = 0x7ffff7df6c3d "", l_ld = 0x600e18, l_next = 0x7ffff7ffe758, l_prev = 0x0}

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

Error loading shared libraries with dlopen()

linux

shared-libraries

dlopen