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 ，一切都很好。

原文由 Elektito 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

POSIX 标准实际上不需要 dlclose 从地址空间卸载库：

尽管 从地址空间 中删除结构不需要 dlclose() 操作，但也没有禁止实现这样做。

资料来源： 开放组基本规范第 6 期

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

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

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

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

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

原文由 Mecki 发布，翻译遵循 CC BY-SA 3.0 许可协议