linux - 使用 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", ...) 时，加载程序会执行以下操作:

1. 打开给定的路径，验证它是具有正确体系结构的合适的 ELF 文件
2. 阅读该文件的动态部分。对于每个 DT_NEEDED(此处为 libconfig.so)，
3. 扫描已经打开的 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

有两种方法可以访问它:

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

2. 以包含 _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 = 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}