dbx

dbx に関する既知の問題と回避策

1. dbx がプロセスに接続されると、データ収集で問題が発生する

   コレクタライブラリ libcollector.so を事前に読み込まずに実行プロセスに dbx を接続すると、多数のエラーが発生します。

   • どのトレーシングデータも収集できません。同期はトレーシング、ヒープトレーシング、または MPI トレーシングを待機します。トレーシングデータはさまざまなライブラリへの割り込み処理によって収集されます。libcollector.so が事前に読み込まれていない場合、割り込み処理ができなくなります。

   • dbx がプロセスに接続されたあとにシグナルハンドラがインストールされ、そのシグナルハンドラが SIGPROF シグナルおよび SIGEMT シグナルを転送しない場合、プロファイルデータと標本データが失われます。

   • プログラムが非同期入出力ライブラリ libaio.so を使用している場合、libaio.so が SIGPROF を使用して非同期の取り消し操作を行うため、時間ベースのプロファイルデータと標本データは失われます。

   • プログラムがハードウェアカウンタライブラリ libcpc.so を使用している場合、コレクタとプログラムが両方ともこのライブラリを使用するため、ハードウェアカウンタオーバーフロープロファイリング実験が破壊されます。dbx がプロセスに接続されたあとハードウェアカウンタライブラリが読み込まれる場合、ハードウェアカウンタ実験は成功しますが、libcpc ライブラリ関数への参照は libcpc.so の検索ではなく一般的検索によって解決されます。

   • プログラムが setitimer(2) を呼び出す場合、コレクタとプログラムの両方がタイマーを使用しているため、時間ベースのプロファイリング実験に失敗する場合があります。

2. dbx で Java コードのデバッグ中に障害が発生する場合がある

   dbx シェルの中で、cd コマンドを実行した場合、もしくは CLASSPATH 環境変数または CLASSPATHX 環境変数を設定した場合、dbx でセグメント例外が発生することがあります。

   回避策:

   • 上記の実行もしくは設定を行わない。

   • 上記の実行もしくは設定を行う前に、すべてのウォッチポイント (表示) を削除する。

3. dbx で Java コードの再デバッグ中に障害が発生する

   Java コードに対して 2 つの debug コマンドを実行することによって、dbx で障害が発生する場合があります。

4. dbx で、アプリケーションをその構築に使用したものと異なる J2SE 上でデバッグすると、例外がスローされる

   アプリケーションを、そのアプリケーションの構築に使用したバージョンの J2SE テクノロジと異なるリリースの J2SE テクノロジの下でデバッグすると、dbx が例外をスローします。

5. RTC 前の監視割り当てが原因でRUA エラーが誤ってレポートされていた

   マルチスレッドプログラムを使用する例外的な状況下で、実行時検査 (RTC) がメモリー割り当ての監視を開始する前に割り当てられた内部スレッド関連データへのアクセスを検出したときに、RTC は RUA エラーを誤ってレポートします。このような状況は、通常のスレッド切り替え動作の一部なので、dbx suppress コマンドを使用することにより、このような誤った RUA レポートを安全に無視できます。

dbx の制限事項と非互換性

Oracle Solaris Studio 12.2 dbx には次の制限事項があります。

• 次の dbx の機能は、ｘ86 ベースのシステム上にある Linux OS では使用できません。

  • 修正継続

    パフォーマンスデータの収集

    次のイベントのブレークポイント

    • fault

      lastrites

      lwp_exit

      sysin

      sysout

      sync

      throw

• 次の dbx の機能は、ｘ64 ベースのシステム上にある Linux OS では使用できません。

  • Java のデバッグ

  • 32 ビットプログラムのデバッグ (-x exec32 オプションを使用して dbx を起動した場合を除く)。

• dbx は、Linux プラットフォームでフォークされたプロセスを追跡できません。また、exec() が呼び出されたときに新しいプログラムに切り替えられません。

• Linux プラットフォームの場合、Korn シェルの pipe 演算子には制約があります。ターゲットプロセスにアクセスする必要がある dbx コマンドはパイプラインの一部として機能しません。たとえば次のコマンドは、dbx をハングアップさせる可能性があります。

      where | head —1

  回避策:

  • Ctrl-C キーを押し、新しい dbx プロンプトを表示します。

  • dbx は大量の情報をキャッシュに書き込むため、前述の例の場合は、次のコマンドシーケンスで機能します。

    where where | head —1

• Linux プラットフォームでのプログラムのデバッグでは、次の問題が発生する可能性があります。

  • プログラムが clone() を使用して独自のスタイルのスレッドを実装している場合、dbx のスレッドサポートによってスレッドが正しく識別されません。

    回避策:

    clone() ではなく、libthread.so を使用してください。

  • Linux OS の threads ライブラリは、その内部機構の一部として SIGSTOP シグナルを使っています。通常、dbx はそれらのシグナルをユーザーから隠し、ほかのソースからの純粋な SIGSTOP シグナルを監視できるようにします。しかし、まれに Linux が予期しない方法で SIGSTOP を使用することがあり、その場合、dbx はシステム生成の SIGSTOP をユーザー生成の SIGSTOP と解釈します。

    回避策:

    ignore コマンドを使用して、SIGSTOP シグナルをキャッチしないよう dbx に指示してください。

  • スレッドは終了するが、Linux から dbx にその終了が報告されないことがあります。この問題は、新しいスレッドライブラリ (NPTL) を利用すると発生することが少なくなります。

    スレッドが終了し、その終了が報告されない場合、dbx は決して起こることのないイベントを待ち、新しいプロンプトを表示しません。この状況は、dbx で cont コマンドを発行したあとでもっとも多く発生しますが、step up コマンドや step コマンド、next コマンドのあとでも発生することがあります。

    回避策:

    • Ctrl-C キーを押すと、dbx が待ち状態を終了し、新しいプロンプトを表示することがあります。

    • Ctrl-C キーが機能しない場合は、いったん dbx を終了して、再起動します。

• g++ コンパイラでコンパイルされているプログラムの場合、C++ 式に関する実行時型情報は得られません。

• 動作中のプロセスに .dbxrc から接続することはできません。このため、.dbxrc ファイルに、コードを実行するコマンドを含めないでください。ただし、別のファイル内にこのようなコマンドを入れておき、dbx source コマンドを使用して、そのファイル内のコマンドを実行することはできます。

• compat=4 のとき、dbx がメンバー関数に対するポインタを不正に復号化します。compat=5 では、この問題は発生しません。

  回避策: 次のコマンドを使って、プログラムを再コンパイルしてください。

  CC —compat=4 —Qoption ccfe —abiopt=pmfun1

  このフラグによって ABI が変更されるため、正規の構築には使用しないでください。

• SPARC V9 (-m64) システムでは、call コマンドや印刷関数の呼び出しの引数または戻り値として小さな入れ子構造を使用することはできません。

• 古い libC.so.5 または libC.so.4 を使用すると、C++ の例外領域で dbx に問題が発生します。不正なスタブや未処理の例外に関する警告メッセージが出力されることがあります。

  回避策: 最新の libC.so.5 をすべてのシステムにインストールしてください。

• Fortran の場合、実行時検査機能を最大限に活用するには、-stackvar コンパイラオプションを使用してください。

• プログラムによっては、-stackvar が正しく機能しないことがあります。そのような場合は、-C コンパイラオプションを試してください。このオプションは、添字の検査を有効にします。

• マルチスレッドアプリケーションで、fork の追跡が正しくないことがあります。

• call コマンドまたは印刷関数の呼び出しを使用すると、マルチスレッドアプリケーションがデッドロック状態になることがあります。

• ファイルがプリコンパイル済みヘッダー (PCH) によって収集されたものの一部であった場合は、ヘッダーファイルの変更に dbx の修正継続機能を使用しないでください。

• dbx コマンド行インタプリタは、CSI (Code Set Independence) をサポートしない旧バージョンの Korn シェル (ksh) です。マルチバイト文字は、dbx コマンド行に入力すると誤って解釈される場合があります。