| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris Studio 12.2: dbx コマンドによるデバッグ |
より高い効果を得るにはより多くのシンボルおよびデバッグ情報が必要になる
x86 プラットフォームでは SIGSEGV シグナルと SIGALTSTACK シグナルが制限される
より高い効果を得るには、十分なパッチ領域を設け、すべての既存コードを含めて 8M バイト以内にする (SPARC プラットフォームのみ)
メモリーリークとは、プログラムで使用するために割り当てられているが、プログラムのデータ領域中のいずれも指していないポインタを持つ、動的に割り当てられたメモリーブロックを言います。そのようなブロックは、メモリーのどこに存在しているかプログラムにわからないため、プログラムに割り当てられていても使用することも解放することもできません。RTC はこのようなブロックを検知し、報告します。
メモリーリークは仮想メモリーの使用を増やし、一般的にメモリーの断片化を招きます。その結果、プログラムやシステム全体のパフォーマンスが低下する可能性があります。
メモリーリークは、通常、割り当てメモリーを解放しないで、割り当てブロックへのポインタを失うと発生します。メモリーリークの例を次に示します。
void
foo()
{
char *s;
s = (char *) malloc(32);
strcpy(s, "hello world");
return; /* no free of s. Once foo returns, there is no */
/* pointer pointing to the malloc’ed block, */
/* so that block is leaked. */
}
リークは、API の不正な使用が原因で起こる可能性があります。
void
printcwd()
{
printf("cwd = %s\n", getcwd(NULL, MAXPATHLEN));
return; /* libc function getcwd() returns a pointer to */
/* malloc’ed area when the first argument is NULL, */
/* program should remember to free this. In this */
/* case the block is not freed and results in leak.*/
}
メモリーリークを防ぐには、必要のないメモリーは必ず解放します。また、メモリーを確保するライブラリ関数を使用する場合は、メモリーを解放することを忘れないでください。
解放されていないブロックを「メモリーリーク」と呼ぶこともあります。ただし、この定義はあまり使用されません。プログラムが短時間で終了する場合でも、通常のプログラミングではメモリーを解放しないからです。プログラムにそのブロックに対するポインタがある場合、RTC はそのようなブロックはメモリーリークとして報告しません。
mel (「メモリーリーク (mel) エラー」を参照)
air (「レジスタ中のアドレス (air)」を参照)
aib (「ブロック中のアドレス (aib)」を参照)
注 - RTC におけるリーク検出の対象は malloc メモリーのみです。malloc を使用していないプログラムで RTC を行なってもメモリーリークは検出されません。
RTC が「リークの可能性」として報告するエラーには 2 種類あります。1 つは、ブロックの先頭を指すポインタが検知されず、ブロックの内部を指しているポインタが見つかった場合です。これは、ブロック中のアドレス (aib) エラーとして報告されます。このようなブロック内部を指すポインタが見つかった場合は、プログラムに実際にメモリーリークが発生しています。ただし、プログラムによってはポインタに対して故意にそのような動作をさせている場合があり、これは当然メモリーリークではありません。RTC はこの違いを判別できないため、本当にリークが発生しているかどうかはユーザー自身の判断で行う必要があります。
もう 1 つのリークの種類は、ブロックを指すポインタがデータ空間に見つからず、ポインタがレジスタ内に見つかった場合に起こります。このケースは、「レジスタ中のアドレス (air)」エラーとして報告されます。レジスタがブロックを不正に指していたり、古いメモリーポインタが残っている場合には、実際にメモリーリークが発生しています。ただし、コンパイラが最適化のために、ポインタをメモリーに書き込むことなく、レジスタのブロックに対して参照させることがありますが、この場合はメモリーリークではありません。プログラムが最適化され、showleaks コマンドでエラーが報告された場合のみ、リークでない可能性があります。詳細については、「showleaks コマンド」を参照してください。
注 - RTC リーク検査では、標準の libc malloc/free/realloc 関数またはこれらの関数に基づいたアロケータを使用する必要があります。ほかのアロケータについては、「実行時検査アプリケーションプログラミングインタフェース」を参照してください。
メモリーリーク検査がオンの場合、メモリーリークの走査は、テスト中のプログラムが終了する直前に自動的に実行されます。検出されたリークはすべて報告されます。プログラムを、kill コマンドによって強制的に終了しないでください。次に、典型的なメモリーリークエラーによるメッセージを示します。
Memory leak (mel):
Found leaked block of size 6 at address 0x21718
At time of allocation, the call stack was:
[1] foo() at line 63 in test.c
[2] main() at line 47 in test.c
UNIX プログラムには通常 main 手続き (FORTRAN 77 では MAIN) が存在します。これは、プログラムに対するトップレベルのユーザー関数です。プログラムは exit(3) が呼び出されるか、main から返った時点で終了します。いずれの場合でも、main のすべての局所変数はプログラムが停止するまでスコープから出ず、それらを指す特定のヒープブロックはすべてメモリーリークとして報告されます。
main 内の局所変数に割り当てられているヒープブロックはプログラムでは解放しないのが一般的です。なぜなら、プログラムは終了しようとしており、exit() を呼び出すことなく main から復帰するためです。これらのブロックがメモリーリークとして報告されないようにするには、main 内の最後の実行可能なソース行にブレークポイントを設定することによって、main から復帰する直前でプログラムを停止します。プログラムがそこで停止したとき、RTC の showleaks コマンドを実行すれば、main() とそこで呼び出されるすべての手続きで参照されなくなったヒープブロックのすべてが表示されます。
詳細については、「showleaks コマンド」を参照してください。
リーク検査を有効にすると、プログラムの終了時にリークレポートが自動的に生成されます。kill コマンドでプログラムを終了した場合を除き、リークの可能性がすべて報告されます。レポートの詳細レベルは、dbx 環境変数 rtc_mel_at_exit (「dbx 環境変数の設定」を参照) で制御します。デフォルトで、非冗長リークレポートが生成されます。
レポートは、リークのサイズによってソートされます。実際のメモリーリークが最初に報告され、次に可能性のあるリークが報告されます。詳細レポートには、スタックトレース情報の詳細が示されます。行番号とソースファイルが使用可能であれば、これらも必ず含まれます。
次のメモリーリークエラー情報が、2 種類の報告のどちらにも含まれます。
|
次に、対応する簡易メモリーリークレポートを示します。
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 つにまとめて報告します。1 つにまとめるか、それぞれ各リークごとに報告するかは、number-of-frames-to-match パラメータによって決まります。このパラメータは、-match m オプション (check -leaks コマンドを実行する場合)、または -m オプション (showleaks コマンドを実行する場合) で指定します。呼び出しスタックが 2 つ以上のリークを割り当てる際に m 個のフレームと一致した場合は、リークは 1 つにまとめて報告されます。
次の 3 つの呼び出しシーケンスを考えてみます。
|
これらのブロックがすべてメモリーリークを起こす場合、m の値によって、これらのリークを別々に報告するか、1 つのリークが繰り返されたものとして報告するかが決まります。m が 2 のとき、ブロック 1 とブロック 2 のリークは 1 つのリークが繰り返されたものとして報告されます。これは、malloc() の上にある 2 つのフレームが共通しているためです。ブロック 3 のリークは、c() のトレースがほかのブロックと一致しないので別々に報告されます。m が 2 よりも大きい場合、RTC はすべてのリークを別々に報告します (malloc はリークレポートでは表示されません)。
一般に、m の値が小さければリークのレポートもまとめられ、m の値が大きければまとめられたリークレポートが減り、別々のリークレポートが生成されます。
RTC からメモリーリーク報告を受けた場合にメモリーリークを修正する方法についてのガイドラインを次に示します。
リークの修正でもっとも重要なことは、リークがどこで発生したかを判断することです。作成されるリーク報告は、リークが発生したブロックの割り当てトレースを示します。リークが発生したブロックは、ここから割り当てられたことになります。
次に、プログラムの実行フローを見て、どのようにそのブロックを使用したかを調べます。ポインタが失われた箇所が明らかな場合は簡単ですが、それ以外の場合は showleaks コマンドを使用してリークの検索範囲を狭くすることができます。showleaks コマンドは、デフォルトでは前回このコマンドを実行したあとに検出されたリークのみを報告するために使用されます。showleaks を繰り返し実行することにより、ブロックがリークを起こした可能性のある範囲が狭まります。
詳細については、「showleaks コマンド」を参照してください。
|