6

モジュール化されたプログラムを構築するために共有ライブラリを試しています。

コンパイルする cpp ファイルは 2 つあります。

共有ライブラリ、コンパイル

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++ある程度の効果はありますが、両方ほどではありません。

4

1 に答える 1

1

1. このコード スニペットが問題を「修正」する理由または方法は?

なぜlibstdc++コードを掘り下げないとわからないのですが、iostreamsライブラリによって割り当てられたメモリは、プログラム全体の期間中割り当てられたままになり、valgrindによって割り当てられたときに問題として報告されると思います。共有ライブラリですが、メインプログラムで割り当てられた場合はそうではありません。

2. 同じバグ修正を提供する同等の独立した (標準ライブラリからの) コード スニペットはどれですか?

まず、まだ到達可能なメモリがおそらく標準ライブラリによって割り当てられているときに、「標準ライブラリから独立した」何かが必要な理由がわかりません。修正は、標準ライブラリをまったく使用しないか、どこでも使用するか、別の方法で使用することです。

std::ios_base第二に、その「修正」は未定義の動作です。これは、標準ライブラリの適切な定義とは異なる方法で再定義することにより、1 つの定義ルールに違反するためです。

同じ動作を取得する正しい方法は、オブジェクトを定義するなど#include <iostream>、main.cppファイル内にあることです。または、変数を定義してから（ただし、型を再定義しないでください）、基本的にはそれが機能するため、それを使用することもできます。<iostream>static std::ios_base::Init#include <ios>staticstd::ios_base<iostream>

于 2013-10-06T16:40:10.293 に答える