私はすべてのアリーナですべてのmalloc_chunkを反復しようとしています。すべてのmallocチャンクを反復する方法(glibc)
がtop_chunkはそれの内部top_chunk、に基づくものアリーナの内側上部チャンクをポイントし、そこのIは、各アリーナを知っているようにしている(メモリリークやメモリ破損調査のために、コア・ファイルに基づいて、デバッグ)コードに基づいprev_sizeとサイズ、(glibcの/のmalloc/malloc.c): Iは、以前の連続チャンクを取得し、その後、ループ1つのアリーナ内のすべてのチャンクができます。 (私はWinDBG:!heap -stat -hのようなサイズと数のチャンクを統計できます)また、prev_sizeとサイズに基づいて、チャンクが壊れているかどうかを確認できます。
アリーナ(malloc_state)には、次のアリーナを指すの次のというメンバー変数があります。それから私はすべてのアリーナのチャンクをループすることができます。
しかし、チャンクが割り当てられていない場合、prev_sizeが無効で、以前のmalloc_chunkを取得する方法が問題になりましたか?または、この方法は正しくありません。
質問の背景:
私たちが持っているメモリリークのバグが(私たちのプロジェクトは、分散ストレージクラスタです)いくつかのオンラインデータノードで報告されたメモリリークです。
我々はテストクラスタ内のバグを再現するためにvalrgindを使用しますが、残念ながら私たちは何を取得:私たちがしたし、その結果どのような
。
私はヒープの詳細を調べようとしましたが、ヒープチャンクを分析し、WinDBG(これはメモリリークとメモリ破損を助長する非常に面白いヒープコマンドを持っていました)私が尋ねた質問によってブロックされました。
私はvalgrind-massifを使って割り当てを分析しています(これは非常に詳細で興味深いと思いますが、どの割り当てにどのくらいのメモリが必要かを示すことができます)。 Massifはいくつかの手がかりを示し、私たちはこれに従ってコードをチェックし、最終的に漏れを見つけました(マップは非常に巨大で、適切な使い方ですが、ホルダークラスのデストラクタで消去します。
glicのmalloc構造の詳細については、gdbヒープのソースコードについて詳しく調べていきます。
これは、GDBの質問やWinDbgの質問のいずれかであるが、それは、両方することはできません私見。私unserstandingから私はWinDbgのタグを削除することをお勧めしたい(「コアダンプ」と「アリーナ」私にはWinDbgの用語のように見えるしていません) –
はい、それはGDBの問題ではなく、WinDbgの質問 –
あなたが 'に興味があるかもしれないですgdb-heap'プロジェクトは、gdbで動作し、glibc mallocアリーナを解剖する方法を知っているPythonコードを含みます。 –