13

リリース バイナリにロードされる共有ライブラリのメモリ リークを見つける方法を知る必要があります。-g オプションでビルドした共有ライブラリを意味しますが、共有ライブラリをロードするバイナリは -g オプションでビルドされていません。

私は次のようにリークレポートを取得します。

==739==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==739==    by 0x84781B1: ???
==739==    by 0x87507F5: ???
==739==    by 0x874CF47: ???
==739==    by 0x874E657: ???
==739==    by 0x874F7C2: ???
==739==    by 0x8779C0C: ???

共有ライブラリからリークのスタック トレースを取得する方法を教えてください。

4

2 に答える 2

9

リークが実際に共有ライブラリから発生していると仮定すると、問題はメインの実行可能ファイルにデバッグがないことではないと思います。

dlclose問題の可能性が高いのは、実行可能ファイルが終了する前に呼び出して共有ライブラリをアンロードしていることです。つまり、valgrindがリークをチェックするようになると、ライブラリがロードされなくなるため、ライブラリのすべてのシンボル情報が失われます。

実行可能ファイルを再構築できる場合、最も簡単な解決策は、ライブラリの呼び出しを一時的に停止しdlcloseて、ライブラリが最後までロードされたままになるようにすることです。

それができない場合は、次のようにを使用LD_PRELOADしてライブラリをロードしたままにしてみてください。

LD_PRELOAD="/path/to/library.so" valgrind my-executable

これにより、ダイナミックリンカをだまして、閉じた後でもライブラリをロードしたままにしておくことができます。

于 2012-10-30T10:02:31.437 に答える
3

前の回答が示唆するように、これは、プログラムが終了する前にライブラリを閉じたため、valgrind でシンボル情報を使用できないためです。

LD_PRELOAD を使用してもうまくいきませんでした。現在、2 つのビルドがあります。明示的に dlclose() を呼び出さないもの。このビルドでは、動的リンクで期待されるように、valgrind は行番号情報を正しく報告します。

于 2013-02-18T06:57:31.967 に答える