リリースバイナリにロードされる共有ライブラリのメモリリークを調べる方法を知る必要があります。私は-gオプションでビルドした共有ライブラリを意味しますが、共有ライブラリをロードするバイナリは-gオプションでビルドされていません。valgrind - 共有ライブラリのメモリリークを見つける
次のようなリークレポートがあります。
==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: ???
共有ライブラリからのリークのスタックトレースを取得する方法を教えてください。
リークが実際にあなたの共有ライブラリから来ていると仮定すると、問題はメインの実行可能ファイルでデバッグが不足しているとは思われません。
実行可能ファイルが終了する前にdlcloseを呼び出して、共有ライブラリをアンロードしている可能性があります。これは、valgrindがリークをチェックするようになると、ライブラリがもうロードされなくなったため、ライブラリのシンボル情報がすべて消えてしまうことを意味します。
実行可能ファイルを再構築できる場合、最も簡単な解決策は、ライブラリが最後までロードされたままになるように、dlcloseを呼び出すことを一時的に停止することです。
あなたは、このように、ロードされたライブラリーを保つためにLD_PRELOADを使用してみて、それを行うことができない場合は、次の
LD_PRELOAD="/path/to/library.so" valgrind my-executable
うまくいけば、それが閉じられた後でも、ライブラリロードを維持するにダイナミックリンカをだまします。
これは、プログラムが終了する前にライブラリを閉じていたため、valgrindにシンボル情報がないためです。
LD_PRELOADを使用すると、私にとってはうまくいきませんでした。私は今2つのビルドを持っています。明示的にdlclose（）を呼び出さないもの。このビルドでは、valgrindはダイナミックリンクの場合と同様に行番号情報を正しく報告します。
dlcloseの後にシンボルのアンロードを無効にするオプションを提供するパッチがありました。パッチは動作し、私は何度もそれを使用しました。しかしパッチは古いバージョンであったので、今は腐っていると思います。 https://bugs.kde.org/show_bug.cgi?id=79362 – k0n3ru
@TomH： "dlcloseの省略"の回避策は、多くの誤検出を招く可能性があることを指摘しておきます。ヒープ上にあった要素を破壊するオブジェクトがスタック上に存在する場合、dlcloseが最初に破壊を行ったため、これらはリークとして出力に表示されます。 – newhouse
また、valgrindが64ビットだが、32 – newhouse