ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
![]() |
Oracle Solaris Studio 12.3: dbx コマンドによるデバッグ Oracle Solaris Studio 12.3 Information Library (日本語) |
より高い効果を得るにはより多くのシンボルおよびデバッグ情報が必要になる
x86 プラットフォームでは SIGSEGV シグナルと SIGALTSTACK シグナルが制限される
より高い効果を得るには、十分なパッチ領域を設け、すべての既存コードを含めて 8M バイト以内にする (SPARC プラットフォームのみ)
リーク検出およびアクセスの両方の検査では、共有ライブラリ libc.so 内の標準ヒープ管理ルーチンを使用する必要があります。これは、RTC がプログラム内のすべての割り当てと解放を追跡できるためです。アプリケーションの多くは、独自のメモリー管理ルーチンを malloc() または free() 関数にかぶせて作成するか、最初から作成します。独自のアロケータ (専用アロケータと呼ばれる) を使用すると、RTC はそれらを自動的に追跡できません。したがって、それらの不正な使用によるリークエラーとメモリーアクセスエラーを知ることができません。
ただし、RTC には専用アロケータを使用するための API があります。この API を使用すると、専用アロケータを、標準ヒープアロケータと同様に扱うことができます。API 自体はヘッダーファイル rtc_api.h に入っており、Oracle Solaris Studio ソフトウェアの一部として配布されます。マニュアルページの rtc_api(3x) には、RTC API 入口の詳細が記載されています。
専用アロケータがプログラムヒープを使用しない場合の RTC アクセスエラーレポートには小さな違いがいくつかあります。標準ヒープブロックを参照するメモリーアクセスエラーが発生した場合、エラーレポートには通常、ヒープブロック割り当ての位置が含まれます。専用アロケータがプログラムヒープを使用しない場合、エラーレポートには割り当て項目が含まれない場合があります。
libumem 内のメモリーアロケータを追跡するために RTC API を使用することは、必須ではありません。RTC は libumem ヒープ管理ルーチンに割り込み、それらを対応する libc 関数にリダイレクトします。