Oracle® Solaris Studio 12.4: dbx コマンドによるデバッグ

印刷ビューの終了

更新: 2015 年 1 月
 
 

メモリーリークの報告を理解する

リーク検査が有効になっている場合は、プログラムが終了したときに自動リークレポートを受信します。kill コマンドでプログラムを終了した場合を除き、リークの可能性がすべて報告されます。レポート内の詳細レベルは、dbxenv 変数 rtc_mel_at_exit によって制御されます。デフォルトでは、簡易リークレポートが生成されます。

レポートは、リークのサイズによってソートされます。実際のメモリーリークが最初に報告され、次に可能性のあるリークが報告されます。詳細レポートには、スタックトレース情報の詳細が示されます。行番号とソースファイルが使用可能であれば、これらも必ず含まれます。

次のメモリーリークエラー情報が、2 種類の報告のどちらにも含まれます。

サイズ

リークのあるブロックのサイズ

場所

リークのあるブロックが割り当てられていた場所

アドレス

リークのあるブロックのアドレス

スタック

check -frames によって制約される、割り当て時の呼び出しスタック

次に、対応する簡易メモリーリークレポートを示します。

Actual leaks report    (actual leaks:    3 total size:    2427 bytes)

 Total      Num of  Leaked      Allocation call stack
 Size       Blocks  Block
                    Address
==========  ====== ==========  =======================================
      1852       2      -      true_leak < true_leak
       575       1    0x22150  true_leak < main

Possible leaks report  (possible leaks:  1  total size:       8 bytes)

 Total      Num of  Leaked      Allocation call stack
 Size       Blocks  Block
                    Address
==========  ====== ==========  =======================================
         8       1    0x219b0  in_block < main

次の例は、標準的な詳細リークレポートを示しています。

Actual leaks report    (actual leaks:         3  total size:    2427 bytes)

Memory Leak (mel):
Found 2 leaked blocks with total size 1852 bytes
At time of each allocation, the call stack was:
    [1] true_leak() at line 220 in "leaks.c"
    [2] true_leak() at line 224 in "leaks.c"

Memory Leak (mel):
Found leaked block of size 575 bytes at address 0x22150
At time of allocation, the call stack was:
    [1] true_leak() at line 220 in "leaks.c"
    [2] main() at line 87 in "leaks.c"

Possible leaks report  (possible leaks:       1  total size:       8 bytes)

Possible memory leak -- address in block (aib):
Found leaked block of size 8 bytes at address 0x219b0
At time of allocation, the call stack was:
    [1] in_block() at line 177 in "leaks.c"
    [2] main() at line 100 in "leaks.c"

リークレポートの生成

showleaks コマンドを使用すると、いつでもリークレポートを要求できます。このコマンドは、最後の showleaks コマンド以降の新しいメモリーリークを報告します。 詳細については、showleaks コマンドを参照してください。

リークの結合

リークレポートの数が多くなるのを避けるため、RTC は同じ場所で割り当てられたリークを自動的に 1 つにまとめて報告します。リークを結合するか、またはリークを個別に報告するかの決定は、check –leaks-match m オプション、または showleaks コマンドの -m オプションで指定される number-of-frames-to-match パラメータによって制御されます。呼び出しスタックが 2 つ以上のリークを割り当てる際に m 個のフレームと一致した場合は、リークは 1 つにまとめて報告されます。

次の 3 つの呼び出しシーケンスを考えてみます。

ブロック 1
ブロック 2
ブロック 3
[1] malloc
[1] malloc
[1] malloc
[2] d() at 0x20000
[2] d() at 0x20000
[2] d() at 0x20000
[3] c() at 0x30000
[3] c() at 0x30000
[3] c() at 0x31000
[4] b() at 0x40000
[4] b() at 0x41000
[4] b() at 0x40000
[5] a() at 0x50000
[5] a() at 0x50000
[5] a() at 0x50000

これらのブロックがすべてメモリーリークを起こす場合、m の値によって、これらのリークを別々に報告するか、1 つのリークが繰り返されたものとして報告するかが決まります。m が 2 のとき、ブロック 1 とブロック 2 のリークは 1 つのリークが繰り返されたものとして報告されます。これは、malloc() の上にある 2 つのフレームが共通しているためです。ブロック 3 のリークは、c() のトレースがほかのブロックと一致しないので別々に報告されます。m が 2 より大きい場合、実行時検査では、すべてのリークを個別のリークとして報告します。malloc は、リークレポートには示されません。

一般に、m の値が小さければリークのレポートもまとめられ、m の値が大きければまとめられたリークレポートが減り、別々のリークレポートが生成されます。