linux ubuntu dlopen,linux – 使用dlopen()加载共享库时出错

我正在开发一个程序,在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已被加载.什么条件可能导致这种行为？

解决方法:

What conditions could cause this behavior?

当你调用dlopen(“/ path_to_plugin / libservices.so”,…)时,加载器执行以下操作：

>打开给定路径,验证它是否是具有正确架构的合适ELF文件

>阅读该文件的动态部分.对于每个DT_NEEDED(此处为libconfig.so),

>扫描已打开的DSO列表,查找完全匹配(这对您失败),

>如果找到,则增加引用计数

>否则尝试在磁盘上找到所需的库.

由于步骤3失败了,所以可以肯定的是,某些东西破坏了已经打开的DSO的加载器列表,或者有人在libconfig.so上调用了dlclose.

如果GDB info shared仍然在步骤3列出了libconfig.so,那么它就是前者.如果没有,那就是后者.

您应该能够通过查看GDB中的_r_debug-> r_map元素并将条目与GDB信息共享输出进行比较来验证损坏.

该列表中的第一个条目将具有主可执行文件,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安装debuginfo包.在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 = 1 # The program does not reference _r_debug itself,

# and debuginfo is not installed. This is probably what you see.

我们来解决这个问题：

cat t2.c

#include

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}

标签：linux,shared-libraries,dlopen

来源： https://codeday.me/bug/20190624/1276037.html