c++ - dlclose 并没有真正卸载共享对象，无论它被调用多少次

Question

我的程序使用 dlopen 加载共享对象，然后使用 dlclose 卸载它。有时会再次加载此共享对象。我注意到静态变量没有重新初始化(这对我的程序很重要)所以我在 dlclose 之后添加了一个测试(dlopen 和 RTLD_NOLOAD) > 看看库是否真的被卸载了。果然还在内存中。

然后我尝试反复调用 dlclose 直到库真正卸载，但我得到的是一个无限循环。这是我用来检查库是否已卸载的代码:

dlclose(handles[name]);

do {
  void *handle = dlopen(filenames[name], RTLD_NOW | RTLD_NOLOAD);
  if (!handle)
    break;

  dlclose(handle);
} while (true);

我的问题是，我的共享对象在 dlclose 之后没有被卸载的可能原因是什么，因为我的 dlopen 调用是它被加载的唯一位置。您能否建议采取行动来追查问题的根源？另外，为什么重复调用 dlclose 没有效果，它们都在减少引用计数，不是吗？

编辑: 刚刚发现只有当我使用 gcc 编译时才会发生这种情况。使用 clang，一切都很好。

Answer 1

POSIX 标准实际上并不要求 dlclose 从地址空间卸载库:

Although a dlclose() operation is not required to remove structures from an address space, neither is an implementation prohibited from doing so.

来源:The Open Group Base Specifications Issue 6

这意味着除了使句柄无效之外，dlclose 根本不需要做任何事情。

有时卸载也会被系统延迟，它只是将库标记为“要删除”，并且会在稍后的某个时间实际执行该操作(为了提高效率或因为现在根本无法执行该操作)。但是，如果您在执行之前再次调用 dlopen，则会清除该标志并重新使用仍在加载的库。

在某些情况下，系统肯定知道库的某些符号仍在使用中，在这种情况下，它不会从地址空间中卸载它以避免悬空指针。在某些情况下，系统不确定它们是否正在使用，但它也无法确定它们没有使用，安全总比抱歉好，在这种情况下，它永远不会真正从内存中删除该库.

还有其他更模糊的情况，具体取决于操作系统类型，通常也取决于版本。例如。一个常见的 Linux 问题是，如果您创建了一个使用 STB_GNU_UNIQUE 符号的库，则该库被标记为“不可卸载”，因此永远不会被卸载。见 here , here (DF_1_NODELETE 表示不可卸载)和here .因此，它还取决于编译器生成的符号或符号类型。尝试在您的库上运行 readelf -Ws 并查找标记为 UNIQUE 的对象。

通常，您不能真正依赖 dlclose 来按预期工作。在实践中，在过去的十年中，我看到它“失败”的次数多于“成功”(嗯，它从来没有真正失败过，它只是经常没有从内存中卸载库；但它按照标准的要求工作)。