Sun JVMは、valgrindで実行すると多くの余分なノイズを吐き出します。これにより、アプリケーションでのメモリの問題の追跡が非常に困難になります。
この状況で小麦をもみ殻から分離するために、偽のメモリエラーを取り除く抑制ファイルまたはVMランタイムモードのいずれかを見つけたいと思います。助言がありますか?
Sun JVMは、valgrindで実行すると多くの余分なノイズを吐き出します。これにより、アプリケーションでのメモリの問題の追跡が非常に困難になります。
この状況で小麦をもみ殻から分離するために、偽のメモリエラーを取り除く抑制ファイルまたはVMランタイムモードのいずれかを見つけたいと思います。助言がありますか?
投稿された質問にはお答えできませんが、どのような問題が発生しているか詳しく教えていただけますか?
言い換えれば、それが...
最近、問題のある Java/C をデバッグする必要がありました (実行から 30 分以上経過した後)。これは、解放された後にメモリを使用していたことが判明しました。私のカスタムメモリリークライブラリであるdmalloc、Valgrindを使用してみましたが、必要に応じて機能するものはありませんでした。
最終的に、free、malloc、calloc、realloc の単純なラッパー セットを作成し、メモリ アドレスとサイズをファイルに出力しました。(GDB内で)中止した後、時間を遡ってメモリが解放された時期と、削除されなかった参照がどこにあったかを突き止めることができました。
問題が C/C++ にあり、デバッガーでエラーをトラップできる場合は、これでうまくいく可能性があります。はい、面倒ですが、数メガバイトの Valgrind 出力をふるいにかけるよりも悪くないかもしれません。
お役に立てば幸いです。
(私が読んだ内容に基づくと) valgrind ほど気の利いたものではありませんが、jmap と jhat を試すことができます。これらのツールを使用すると、実行中のプロセスのスナップショットを取得して、何が起こっているかを確認できます。私はこの手法を単純なメモリ リークに使用しましたが、うまくいきました。ただし、メモリの問題が jvm 以外の割り当てによって引き起こされている場合、これは役に立ちません。