First off, this isn't a Linux kernel bug—it's a behavior rooted in the GNU toolchain's C++ runtime and the constraints of static linking in dynamically loadable objects (DSOs). Let's break down why this happens and how to fix it.

原因分析 #

• 静态链接libstdc++的固有局限：当你把libstdc静态链接到DSO中时，库的全局状态（比如内存分配器缓存、静态初始化痕迹、内部运行时结构）并没有被设计为能在dlclose时完全清理。和动态链接的libstdc不同（它在整个进程中共享一个实例），静态链接的副本会携带自己的运行时状态——其中很大一部分绑定到进程的全局内存（比如glibc的malloc内存池），这些内存不会随DSO卸载而被回收。
• GNU唯一符号不是唯一问题：即使启用了--disable-gnu-unique-object和--no-gnu-unique，其他C++运行时机制也可能导致泄漏：
  • 为静态对象注册的__cxa_atexit清理函数在DSO卸载时可能无法完全释放内存。
  • Glibc的malloc使用进程级内存池和线程缓存，DSO中静态libstdc++分配的内存会被保存在这些池里，而内存池不会因DSO卸载自动收缩。
• GCC 5.3.1的版本局限：这个较老的GCC版本在静态链接libstdc++的DSO卸载支持上存在已知缺陷，后续版本（GCC 7+）修复了很多这类边缘场景的问题。

可行解决方案 #

1. 尽量避免静态链接libstdc++（优先推荐） #

静态链接libstdc++到DSO中，对于需要dlclose/dlopen重新初始化的场景几乎总是会出问题。替代方案：

• 让DSO动态链接libstdc++。这样运行时会在整个进程中共享一个全局实例，dlclose可以正确清理DSO专属状态，不会在全局内存池中留下孤立内存。
• 在DSO的编译参数中添加-fno-gnu-unique（不只是编译GCC时加），禁用STB_GNU_UNIQUE绑定，确保dlclose不会被忽略。

2. 优化DSO的内存使用 #

• 移除不必要的静态全局对象：检查DSO代码，删除那些分配大量内存的静态局部变量或全局对象。如果必须使用，在标记为__attribute__((destructor))的析构函数中添加显式清理逻辑。
• 在DSO析构函数中显式释放内存：创建一个清理函数，释放所有手动分配的内存（容器、自定义对象等），并注册它在dlclose时运行：

  __attribute__((destructor)) void dso_cleanup() {
      // 在这里释放所有DSO专属的已分配内存
  }
  

• 调整malloc行为：调试或特定场景下，可以设置环境变量MALLOC_TRIM_THRESHOLD_=0，强制glibc的malloc立即将释放的内存归还给系统。注意这会影响性能，谨慎使用。

3. 升级GCC版本 #

如果条件允许，升级到GCC 7或更新版本。这些版本对静态链接场景下的DSO卸载支持有显著改进，修复了很多和静态初始化、运行时清理相关的内存泄漏问题。

4. 验证并调整编译参数 #

• 确认DSO中已禁用STB_GNU_UNIQUE符号：运行readelf -s your_dso.so | grep UNIQUE，如果没有输出，说明参数生效。
• 使用gold链接器时，添加-Wl,--gc-sections参数，剥离DSO中未使用的代码和数据，减少内存占用和潜在的未使用静态对象泄漏。

5. 使用自定义内存分配器 #

为DSO实现一个自定义内存分配器，跟踪所有分配的内存。在dlclose时，可以遍历所有跟踪的分配记录，一次性释放所有内存，彻底绕过glibc的全局malloc内存池。

调试步骤 #

要精准定位泄漏点：

• 使用valgrind --leak-check=full --trace-children=yes ./your_program生成详细的泄漏报告，查看泄漏内存的地址和来源，区分是libstdc++内部、你的代码还是glibc malloc导致的泄漏。
• 监控/proc/[pid]/smaps而非仅maps——它提供了每个内存段的详细使用情况，更容易追踪DSO卸载后残留的内存部分。

内容的提问来源于stack exchange，提问作者TQ.Liu