| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris Studio 12.2 リリースの新機能 |
1. Oracle Solaris Studio 12.2 リリースの概要
-instances=static で -xipo または -xcrossfile があると、リンクに失敗する
デバッグツールから、メンバー関数に余分な先行パラメータがあるという誤ったメッセージが返される
大域的ではない名前空間のオブジェクトをテンプレートから参照できない
dbx がプロセスに接続されると、データ収集で問題が発生する
コレクタライブラリ libcollector.so を事前に読み込まずに実行プロセスに dbx を接続すると、多数のエラーが発生します。
どのトレーシングデータも収集できません。同期はトレーシング、ヒープトレーシング、または MPI トレーシングを待機します。トレーシングデータはさまざまなライブラリへの割り込み処理によって収集されます。libcollector.so が事前に読み込まれていない場合、割り込み処理ができなくなります。
dbx がプロセスに接続されたあとにシグナルハンドラがインストールされ、そのシグナルハンドラが SIGPROF シグナルおよび SIGEMT シグナルを転送しない場合、プロファイルデータと標本データが失われます。
プログラムが非同期入出力ライブラリ libaio.so を使用している場合、libaio.so が SIGPROF を使用して非同期の取り消し操作を行うため、時間ベースのプロファイルデータと標本データは失われます。
プログラムがハードウェアカウンタライブラリ libcpc.so を使用している場合、コレクタとプログラムが両方ともこのライブラリを使用するため、ハードウェアカウンタオーバーフロープロファイリング実験が破壊されます。dbx がプロセスに接続されたあとハードウェアカウンタライブラリが読み込まれる場合、ハードウェアカウンタ実験は成功しますが、libcpc ライブラリ関数への参照は libcpc.so の検索ではなく一般的検索によって解決されます。
プログラムが setitimer(2) を呼び出す場合、コレクタとプログラムの両方がタイマーを使用しているため、時間ベースのプロファイリング実験に失敗する場合があります。
dbx で Java コードのデバッグ中に障害が発生する場合がある
dbx シェルの中で、cd コマンドを実行した場合、もしくは CLASSPATH 環境変数または CLASSPATHX 環境変数を設定した場合、dbx でセグメント例外が発生することがあります。
回避策:
上記の実行もしくは設定を行わない。
上記の実行もしくは設定を行う前に、すべてのウォッチポイント (表示) を削除する。
dbx で Java コードの再デバッグ中に障害が発生する
Java コードに対して 2 つの debug コマンドを実行することによって、dbx で障害が発生する場合があります。
dbx で、アプリケーションをその構築に使用したものと異なる J2SE 上でデバッグすると、例外がスローされる
アプリケーションを、そのアプリケーションの構築に使用したバージョンの J2SE テクノロジと異なるリリースの J2SE テクノロジの下でデバッグすると、dbx が例外をスローします。
RTC 前の監視割り当てが原因でRUA エラーが誤ってレポートされていた
マルチスレッドプログラムを使用する例外的な状況下で、実行時検査 (RTC) がメモリー割り当ての監視を開始する前に割り当てられた内部スレッド関連データへのアクセスを検出したときに、RTC は RUA エラーを誤ってレポートします。このような状況は、通常のスレッド切り替え動作の一部なので、dbx suppress コマンドを使用することにより、このような誤った RUA レポートを安全に無視できます。
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 コマンド行に入力すると誤って解釈される場合があります。
Linux で Oracle Message Passing Toolkit 8.2 または 8.2.1 を使用している場合、回避策が必要な場合があります。バージョン 8.1 または 8.2.1c では、または Oracle Solaris Studio コンパイラを使用している場合はすべてのバージョンで、回避策は必要ありません。
Oracle Message Passing Toolkit のバージョンは、/opt/SUNWhpc/HPC8.2.1 などのインストールパスで示されています。または、mpirun —V と入力して表示される次のような出力では、斜体の部分でバージョンが示されています。
mpirun (Open MPI) 1.3.4r22104-ct8.2.1-b09d-r70
アプリケーションを GNU または Intel コンパイラでコンパイルし、Oracle Message Passing Toolkit 8.2 または 8.2.1 を MPI 用に使用している場合、MPI の状態データを取得するには、Oracle Message Passing Toolkit の link コマンドで -WI および --enable-new-dtags オプションを使用する必要があります。これらのオプションを使用すると実行可能ファイルで RPATH に加えて RUNPATH が定義され、MPI 状態ライブラリが LD_LIBRARY_PATH 環境変数で有効になります。
ここでは、これまでにわかっている dmake ソフトウェアの問題点とその回避策について説明します。
分散モードで dmake を使用した場合に何か問題が発生する場合は、次の点を確認してください。
$HOME 環境変数がアクセス可能なディレクトリに設定されているか
% ls -la $HOME
ファイル $HOME/.dmakerc が存在するか、このファイルの読み取りが可能か、このファイルの情報が正しいか
% cat $HOME/.dmakerc
$HOME/.dmakerc ファイルに示されているすべてのホストが稼働しているか (/usr/sbin/ping コマンドを使用して各ホストをチェック)
% /usr/sbin/ping $HOST
% /$$HOST には、$HOME/.dmakerc ファイルでホストとして示されているシステムの名前を指定してください。
dmake バイナリのパスが正しいか (dmake、rxm、および rxs コマンドを使用)
% which dmake
% which rxm
% which rxs 各ホスト上のリモートログイン (rsh) はパスワードなしで可能か。また、各リモートログインは妥当な時間内 (2 秒未満) に行えるか。
% time rsh $HOST uname -a
各ホスト上にファイル /etc/opt/SPROdmake/dmake.conf が存在するか。このファイル内の情報は正しいか。このファイルが存在しない場合は、dmake はこのシステムでジョブを 1 つだけ分散します。
% rsh $HOST cat /etc/opt/SPROdmake/dmake.conf
各ホストの dmake バイナリのパスが正しいか
% rsh $HOST `which dmake`
% rsh $HOST `which rxm`
% rsh $HOST `which rxs` 各ホストから構築領域を利用できるか (rwx)
% cd $BUILD
% rm $HOST.check.tmp
% echo "Build area is available from host $HOST" > $HOST.check.tmp
% rsh $HOST cat $BUILD/$HOST.check.tmp
$BUILD には、構築領域のフルパスを指定してください。
その $HOME は各ホストから使用可能か
% cd $HOME
% rm $HOST.check.tmp
% echo "HOME is available from host $HOST" > $HOST.check.tmp
% rsh $HOST cat $HOME/$HOST.check.tmp次の要件を満たしていれば、どのマシンも構築サーバーとして使用できます。
dmake ホスト (構築プロセスの開始に使われるマシン) から、構築サーバー上でコマンドをリモート実行するためのパスワードを要求されることなく、rsh を使用できる必要があります。
dmake ソフトウェアがインストールされている bin ディレクトリに構築サーバーからアクセスできる必要があります。デフォルトでは、dmake は構築サーバー上の dmake 実行可能ファイルへの論理パスが dmake ホスト上の実行可能ファイルと同じものであると仮定します。この仮定を無効にするには、実行時構成ファイルのホストエントリの属性としてパス名を指定します。
ホスト上に /etc/opt/SPROdmake/dmake.conf ファイルが存在していて、読み取り可能であり、適切な情報が含まれている。このファイルが存在しない場合は、dmake はこのシステムでジョブを 1 つだけ分散します。
|