内存仍然可以访问的错误已修复，但为什么呢？

Question

我正在尝试使用共享库来构建模块化程序。

有两个cpp文件要编译：

共享库，编译用

g++ -fPIC -shared module.cpp -o module.so

//module.cpp
#include <iostream>

使用共享库的文件，编译使用

g++ src/main.cpp -ldl -o 二进制

或

g++ -DFIX src/main.cpp -ldl -o 二进制

//main.cpp
#include <dlfcn.h>
#ifdef FIX
# include <iostream>
#endif

int main()
{
   void* h = dlopen("./module.so", RTLD_LAZY);
   if ( h )
   {
      dlclose(h);
   }
}

FIX 未定义，valgrind 报告大量仍可访问的内存（5,373 字节），FIX 定义，没有内存泄漏。

在共享库中使用iostream 有什么问题？

g++-4.6、g++-4.7 和 g++-4.8 会出现此问题。 g++-4.4 没有显示这种行为。遗憾的是，我没有其他编译器可供测试（因此我不想切换到 g++-4.4）。

更新：

使用附加标志-static-libstdc++ -static-libgcc 编译共享库文件可以减少泄漏块的数量，但不能完全减少。 -static-libgcc 单独没有效果，-static-libstdc++ 有一些效果，但效果不如两者。

Answer 1

1。这段代码 sn-p 为什么或如何“修复”问题？

我不确定为什么不深入研究 libstdc++ 代码，但我假设 iostreams 库分配的内存在整个程序期间一直分配，当它被 valgrind 报告为问题时在共享库中分配，但在主程序中分配时不分配。

2。什么等效的、独立的（来自标准库的）代码 sn-p 提供了相同的错误修复？

首先，我不知道你为什么想要一些“独立于标准库”的东西，而仍然可以访问的内存可能是由标准库分配的。解决方法是要么在任何地方完全不使用标准库，要么以不同的方式使用它。

其次，“修复”是未定义的行为，因为您将std::ios_base 重新定义为与标准库中的正确定义不同，从而违反了单一定义规则。

获得相同行为的正确方法是在您的main.cpp 文件中使用#include <iostream>，其中<iostream> 定义了一个static std::ios_base::Init 对象。或者，只需 #include <ios>，然后定义 static 变量（但不要重新定义 std::ios_base 类型），但这基本上就是 <iostream> 所做的，所以你不妨使用它。