35

バグのある (メモリ リークが発生した) ソフトウェアを使用しています。証拠として、1GB の core.dump ファイルがあります。ヒープ サイズは 900MB であるため、明らかに何かが割り当てられますが、メモリは解放されません。

だから、私はこのように調べるメモリ領域を持っています。

(gdb) x/50000s 0x200000000

ただし、これは、どのオブジェクトまたは構造体が解放されていないかを肉眼で推測するだけでは困難です。トレースする私のアイデアは、「gdb 形式の出力をファイルに保存し、パターン マッチを実行して、どのマジック ストリングが最も多く出現するかを確認する」ことです。だから、ここに私の質問があります：

アナライザーを作成できるように、次のコマンドの出力をテキストファイルに保存するにはどうすればよいですか?

(gdb) x/10000000s 0x20000000    <-- I need this output into a file
4

3 に答える 3

16

アナライザーを作成できるように、次のコマンドの出力をテキストファイルに保存するにはどうすればよいですか?

 (gdb) x/10000000s 0x20000000

それは実際には非常に簡単です：

(gdb) set height 0    # prevent GDB from stopping every screenfull
(gdb) set logging on  # GDB output is now also copied into gdb.txt
(gdb) x/10000000s 0x20000000
(gdb) quit

ほら、で出力を楽しんでくださいgdb.txt。

バグのある (メモリ リークが発生した) ソフトウェアを使用しています。... "gdb 形式の出力をファイルに保存し、パターン マッチを実行して、どのマジック ストリングが最も多く出現するかを確認します。"

その考えでは、満足のいく結果が得られる可能性はほとんどありません。検討：

void some_function() {
   std::vector<string> *v = new std::vector<string>();
   // code to insert and use 1000s of strings into "v".
   return;  // Oops: forgot to delete "v".
}

「最も出てくる魔法の文字列を効果的に見る」ことができたとしても、すべての文字列が漏れていることに気付くでしょう。しかし、それらは問題ではなく、「v」のリークが問題です。

したがって、実際に必要なのは、割り当てられた領域が他の割り当てられた領域を指すグラフを作成し、そのグラフの「ルート」を見つけることです。これを手作業で行うことはほぼ不可能です。

では、メモリリークを見つけるのに役立つ可能性が高いものは何ですか? 幸いなことに、この問題を解決できるツールがたくさんあります。

于 2013-04-19T05:20:28.087 に答える