Linux迭代调用共享动态库导致segment fault

2023年5月22日 295次阅读 来源: 928e93967d0f

项目需要我编写了一个动态库libs2cShareLib.so供同组同事Carson使用，他也也编了一个动态库libnative.so，并在这个库内部使用我提供的接口。
昨天下午CAE部门的Evan编写的一个动态库libcapi_pcie.so中用到了libnative.so。这样Evan的一个工程下就有了3个动态库libcapi_pcie.so， libnative.so和libs2cShareLib.so,他的编译命令行是这样的：

gcc -rdynamic -DKERNEL_64BIT -m64 -DLINUX -Wall -o main main.c -ldl

并没有指定链接相关动态库，而是在程序中采用手动方式加载动态库：

void *CAPI_LIB_handle = dlopen(”./capi_pcie.so“, RTLD_LAZY); `
......
dlclose(CAPI_LIB_handle);

编译完，运行”./main”,前面都运行正常，到最后程序退出时出现segment fault。

我们尝试了几种改动都可以避免出现segment fault：

  1. 注释掉代码最后(CAPI_LIB_handle);
  2. 注释掉libnative.so中调用libs2cShareLib.so的部分代码并重新编译libnative.so;

问题貌似已经定位到是libs2cShareLib.so的问题了，但这个库是我写的，经过反复测试的，我把自己的测试程序拿到Evan那里跑也是OK的。难道是动态库中调用动态库会有什么限制？我又写了个自测试程序测试libnative.so。编译参数：

gcc -o test -lnative -lstdc++ main.cpp

结果一切正常。
只能查找我测试程序和Evan程序的不同了，不同点有两个：

  1. 我的测试程序中的调用关系是：test->libnative.so->libs2cShareLib.so,两层动态库调用；而Evan的程序中是main->libcapi_pcie.so->libnative.so->libs2cShareLib.so,三层动态库调用。
  2. 我的测试程序中我是用链接器链接要用到的动态库；而Evan的程序中是采用手动load的方式。

一个一个来排查，针对第一点，让Evan修改他的程序，直接load libnative.so,结果还是出错，说明不是动态库调用层数的关系了。
针对第二点，修改Evan的编译选项，指定链接要用到的相关动态库，而不是程序中手动load。运行，结果正确！！！
说明不是动态库本身的问题了，难道说多层动态库调用不能手动load？带着这个疑问找老大，老大看了一下Evan代码，指着void *CAPI_LIB_handle = dlopen(”./capi_pcie.so“, RTLD_LAZY);这一行，会不会是这个load参数的问题。百度了一下：

void * dlopen( const char * pathname, int mode);

函数描述：
mode是打开方式，其值有多个，不同操作系统上实现的功能有所不同，在linux下，按功能可分为三类：

  1. 解析方式
    RTLD_LAZY：在dlopen返回前，对于动态库中的未定义的符号不执行解析（只对函数引用有效，对于变量引用总是立即解析）。
    RTLD_NOW： 需要在dlopen返回前，解析出所有未定义符号，如果解析不出来，在dlopen会返回NULL，错误为：: undefined symbol: xxxx…….
  2. 作用范围，可与解析方式通过“|”组合使用。
    RTLD_GLOBAL：动态库中定义的符号可被其后打开的其它库重定位。
    RTLD_LOCAL： 与RTLD_GLOBAL作用相反，动态库中定义的符号不能被其后打开的其它库重定位。如果没有指明是RTLD_GLOBAL还是RTLD_LOCAL，则缺省为RTLD_LOCAL。
  3. 作用方式
    RTLD_NODELETE： 在dlclose()期间不卸载库，并且在以后使用dlopen()重新加载库时不初始化库中的静态变量。这个flag不是POSIX-2001标准。
    RTLD_NOLOAD： 不加载库。可用于测试库是否已加载(dlopen()返回NULL说明未加载，否则说明已加载），也可用于改变已加载库的flag，如：先前加载库的flag为 RTLD_LOCAL，用dlopen(RTLD_NOLOAD|RTLD_GLOBAL)后flag将变成RTLD_GLOBAL。这个flag不是POSIX-2001标准。
    RTLD_DEEPBIND：在搜索全局符号前先搜索库内的符号，避免同名符号的冲突。这个flag不是POSIX-2001标准。

果断把RTLD_LAZY改成RTLD_NOW,重新编译运行，正常，也没有segment fault了。
终于找到原因了，RTLD_LAZY在调用dlopen时为了节省时间，并没有解析所用到的未定义符号，而是在用到的时候再来解析；而RTLD_NOW就是解析所有用到的符号，类似于链接器链接指定动态库的效果。
但还是有个问题搞不明白，问什么在libnative.so中注释掉调用libs2cShareLib.so的代码, RTLD_LAZY方式就是可以的呢？
main->libcapi_pcie.so->libnative.so->libs2cShareLib.so程序结束出现segment fault错误；
main->libcapi_pcie.so->libnative.so程序结束，正常退出。
希望有大神帮忙解惑，小弟感激不尽！

搬自:我的CSDN

    原文作者：928e93967d0f
    原文地址: https://www.jianshu.com/p/61be9d9a095d
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞