問題タブ [libumem]

言う

solaris10のulibmemは、リークとして60バイトと30バイトのみを表示しますが、128バイトもリークを表示しないのはなぜですか？

libumem は、Solaris OS または他の OS でのみ使用できますか?

Solarisでlibumemを使用する方法を知りたいです。http://www.unix.com/man-page/OpenSolaris/3malloc/umem_debug/に従って、すべてのオプションを使用してプロセスを開始した場合、どのように出力を取得しますか？

結果のテキストファイルを入手できますか？

私は同じようにHP-UXでwdbを使用しました。これにより、プログラムの終了後にテキストファイルが生成され、後で分析できます。libumemについても同じことができますか？

注：これはリモートデバッグであり、その後までシステムにアクセスできません。

JNI（C ++コード）を多用するJavaアプリケーションでメモリリークをチェックする必要があります。libumemをアタッチすると、SIGKILL（Signal 9）を受信した後にプロセスが終了します。

プロセスはいつSIGKILLを受け取りますか？libumemはどのようにそれを引き起こしていますか？

OS：Solaris8。

Linux、Solaris、および AIX で実行される C アプリケーションがあります。Totalview の MemoryScape などのツールを使用して、Linux でのメモリ リークを追跡しましたが、100% クリーンです。ただし、Solaris で小さなリークがあることに気付きました。

そのため、Solaris で「libumem」を使用してリークを見つけようとしました。

私のアプリケーションは、(サブプロセス呼び出しを介して) 「ユーザー出口」を呼び出すか、呼び出しません。

したがって、ユーザー出口なしでアプリケーションを実行すると (したがって、サブプロセス呼び出しはありません)、libumem は 100% 動作します....そして、まだリークは見られません...

LD_PRELOAD=libumem.so UMEM_DEBUG=audit ./myapplication config.ini

しかし、メインアプリケーションがサブプロセスを呼び出すようにユーザー出口呼び出しをオンにすると、実行時にサブプロセスによって次のように STDOUT に出力されます。

ld.so.1: userexit_proxy: fatal: libmapmalloc.so.1: そのようなファイルまたはディレクトリはありません

「libumem」を使用しない場合、アプリケーションは 100% 実行されることに注意してください...(ほんのわずかなメモリ リークがまだあります)

現在、私のアプリケーションは 64 ビットでコンパイルされており、/usr/lib/libmapmalloc.so.1 が 32 ビットであることに気付きましたが、違いはありません....

サブプロセスも呼び出すアプリケーションで libumem を使用する方法はありますか?

注：環境全体に変数をエクスポートしようとしましたが、まだ運がありません

export LD_PRELOAD=libumem.so export UMEM_DEBUG=audit

また、私が間違っている場合は修正してください。ただし、サブプロセスが完了すると、そのサブプロセスの「リークしたメモリ」は自動的に解放されますか? したがって、サブプロセス呼び出しから Solaris にリークが発生していないと仮定できますか?

この点でどんな助けでも大歓迎です

助けてくれてありがとう

リントン

「メモリ リークをなくす」ことを試みているアプリケーションがあります。Totalview の MemoryScape を使用して Linux でしっかりとしたテストを行いましたが、リークは見つかりませんでした。アプリケーションを Solaris (SPARC) に移植しましたが、見つけようとしているリークがあります...

Solarisで「LIBUMEM」を使用しましたが、リークも発生しないようです...

これが私の起動コマンドです：

次に、Solaris の PRSTAT をすぐにチェックして、起動時のメモリ使用量を確認しました。

その後、アプリケーションに何千ものメッセージを送信し始めました...そして、時間の経過とともに PRSTAT が成長しました..

そして、最終的に停止する直前に：

ここで興味深いのは、このアプリケーションで LIBUMEM を使用すると、次のように 48 MB のメモリが表示されることです。

「7 つの特大リーク、851968 バイト」は、アプリケーションを介して 10 メッセージまたは 10000 メッセージを送信しても変化しません...常に「7 つの特大リーク、851968 バイト」です。それは「libumem」によるとアプリケーションがリークしていないということですか？

非常に苛立たしいのは、Linux ではメモリが一定のままであり、決して変化しないことです....しかし、Solaris では、このゆっくりとした、しかし着実な成長が見られます。

これが何を意味するか分かりますか？libumem を正しく使用していますか? ここで PRSTAT がメモリの増加を示している原因は何ですか?

これに関するどんな助けも大歓迎です....百万に感謝します。

libumem のレッドゾーンの上書きをキャッチすることは可能ですか? libumem を使用してメモリ破損を分析したところ、一部のブロックのレッドゾーンが次のようになっていることがわかりました。

これ以降のすべてのブロックは同じ方法で交換されます。どこでどのように発生する可能性があるかを調べる必要があります。

Solaris (SunOS m1001 5.10 sun4v sparc) で実行されているプロセスがあり、使用される仮想メモリの合計を監視していました。

定期的に ps を実行すると、VSZ が 80k バイトのジャンプで時間の経過とともに直線的に増加し、4GB の制限に達するまで増加し続け、その時点でアドレス空間が不足し、物事が崩壊し始めることが示されました。

私はメモリ リークを疑い、pmap でさらに調査することにしました。しかし、pmap は、VSZ がまったく成長しておらず、むしろ安定していることを示しています。また、すべてのファイル マップ、共有メモリ マップ、およびヒープが同じサイズに保たれました。

私の最初の質問は、ps と pmap が同じプロセスに対して異なる VSZ を生成するのはなぜですか?

ヒープ サイズの計算方法が異なると想像できます (たとえば、ヒープ使用量と最高ヒープ ポインター)。次に、libumem と mdb を使用して、割り当てられたメモリに関する詳細なレポートをさまざまな時点で作成しましたが、割り当てられたメモリにまったく違いがないことに気付きました。

私の 2 番目の質問は、ps によって報告された VSZ の増加の原因を突き止める最善の方法は何かということです。