| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris Studio 12.3 リリースの新機能 Oracle Solaris Studio 12.3 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris Studio 12.3 リリースの新機能 Oracle Solaris Studio 12.3 Information Library (日本語) |
1. Oracle Solaris Studio 12.3 リリースの紹介
-instances=static で -xipo または -xcrossfile があると、リンクに失敗する
大域的ではない名前空間のオブジェクトをテンプレートから参照できない
アーカイブライブラリ内の F95 モジュールが実行可能ファイルに含まれない
dbx がプロセスに接続された場合のデータ収集の問題
コレクタライブラリ libcollector.so を事前にロードしないで dbx を実行中のプロセスに接続すると、さまざまなエラーが発生する可能性があります。
どのトレーシングデータも収集できません。同期はトレーシング、ヒープトレーシング、または MPI トレーシングを待機します。トレースデータの収集は各種ライブラリに割り込むことで行われますが、libcollector.so が事前にロードされていなければ、割り込みを行えません。
dbx がプロセスに接続されたあとにシグナルハンドラがインストールされ、そのシグナルハンドラが SIGPROF シグナルおよび SIGEMT シグナルを転送しない場合、プロファイルデータと標本データが失われます。
プログラムが非同期入出力ライブラリ libaio.so を使用している場合、libaio.so が SIGPROF を使用して非同期の取り消し操作を行うため、時間ベースのプロファイルデータと標本データは失われます。
プログラムがハードウェアカウンタライブラリ libcpc.so を使用している場合、コレクタとプログラムが両方ともこのライブラリを使用するため、ハードウェアカウンタオーバーフロープロファイリング実験が破壊されます。dbx がプロセスに接続されたあとでハードウェアカウンタライブラリがロードされた場合、libcpc.so 内での検索ではなく一般的な検索によって libcpc ライブラリ関数への参照が解決されるのであれば、ハードウェアカウンタ実験が成功する可能性があります。
プログラムが setitimer(2) を呼び出す場合、コレクタとプログラムの両方がタイマーを使用しているため、時間ベースのプロファイリング実験に失敗する場合があります。
Java コードのデバッグ中に dbx がクラッシュする可能性がある
dbx シェル内から cd コマンドを発行したり、CLASSPATH 環境変数または CLASSPATHX 環境変数を設定したりすると、その後、dbx がセグメント例外でクラッシュする可能性があります。
回避策:
上記の実行もしくは設定を行わない。
上記の実行もしくは設定を行う前に、すべてのウォッチポイント (表示) を削除する。
Java コードの再デバッグ時に dbx がクラッシュする
Java コードに対してデバッグコマンドを 2 回続けて発行すると、dbx がクラッシュする可能性があります。
アプリケーションを構築時とは異なる J2SE 上でデバッグすると、dbx から例外がスローされる
アプリケーションの構築時に使用した J2SE テクノロジのバージョンとは異なるリリースの J2SE テクノロジの下でそのアプリケーションをデバッグすると、dbx から例外がスローされます。
RTC 前の監視割り当てが原因でRUA エラーが誤ってレポートされていた
マルチスレッドプログラムを使用する例外的な状況下で、実行時検査 (RTC) がメモリー割り当ての監視を開始する前に割り当てられた内部スレッド関連データへのアクセスを検出したときに、RTC は RUA エラーを誤ってレポートします。このような状況は、通常のスレッド切り替え動作の一部なので、dbx suppress コマンドを使用することにより、このような誤った RUA レポートを安全に無視できます。
Oracle Solaris Studio 12.3 の dbx には次の制限があります。
動作中のプロセスに .dbxrc から接続することはできません。このため、.dbxrc ファイルに、コードを実行するコマンドを含めないでください。ただし、別のファイル内にこのようなコマンドを入れておき、dbx source コマンドを使用して、そのファイル内のコマンドを実行することはできます。
dbx は、-compat=4 オプションでコンパイルされたメンバー関数へのポインタを不適切に復号化します。この問題は、-compat=5 オプションでは発生しません。
SPARC V9 (-m64) システムでは、call コマンドや印刷関数の呼び出しの引数または戻り値として小さな入れ子構造を使用することはできません。
libC.so.5 または libC.so.4 の古いコピーを使用すると、C++ 例外の領域で dbx の問題が発生することがあります。不正なスタブや未処理の例外に関する警告メッセージが出力されることがあります。
回避策: 最新の libC.so.5 をすべてのシステムにインストールしてください。
Fortran ユーザーは、実行時検査をフル活用できるように、-stackvar オプションを使用してコンパイルするようにしてください。
一部のプログラムは、-stackvar オプションを使用すると正しく動作しないことがあります。そのような場合には、RTC を使用せずに配列添字検査をオンにする -C コンパイラオプションを試してください。
マルチスレッドアプリケーションで、fork の追跡が正しくないことがあります。
マルチスレッドアプリケーションで call コマンドまたは印刷関数呼び出しを使用すると、デッドロック状態が発生する可能性があります。
あるヘッダーファイルがプリコンパイル済みヘッダー (PCH) コレクションの一部になっていた場合、dbx の修正継続機能を使用してそのファイルを変更しないでください。
dbx コマンド行インタプリタは、CSI (Code Set Independence) をサポートしない旧バージョンの Korn シェル (ksh) です。マルチバイト文字は、dbx コマンド行に入力すると誤って解釈される場合があります。
dbx の次の機能は、Linux OS では使用できません。
修正継続
パフォーマンスデータの収集
次のイベントのブレークポイント
fault
lastrites
lwp_exit
sysin
sysout
sync
throw
Java のデバッグ
32 ビットプログラムのデバッグ (-x exec32 オプションを使用して dbx を起動しない場合)。
Linux プラットフォームでのプログラムのデバッグでは、次の問題が発生する可能性があります。
dbx は、exec() の呼び出し時に、Linux プラットフォーム上でフォークされたプロセスを追跡したり新しいプログラムに変更したりできません
Linux プラットフォームの場合、Korn シェルの pipe 演算子には制約があります。ターゲットプロセスにアクセスする必要がある dbx コマンドはパイプラインの一部として機能しません。たとえば、次のコマンドではおそらく dbx がハングアップします。
where | head -1
回避策:
Ctrl-C キーを入力して新しい dbx プロンプトを表示します。
dbx は多くの情報をキャッシュに格納するので、前述の例の場合、次の一連のコマンドが動作します。
where where | head —1
プログラムが clone() を使用して独自のスタイルのスレッドを実装している場合、dbx のスレッドサポートではスレッドが正しく識別されません。
回避策:
clone() ではなく、libthread.so を使用してください。
Linux OS の threads ライブラリは、その内部機構の一部として SIGSTOP シグナルを使っています。通常、dbx はこれらのシグナルをユーザーから隠蔽し、ユーザーがほかのソースからの本物の SIGSTOP シグナルを監視できるようにします。Linux OS はときどき SIGSTOP を予期しない方法で使用しますが、その際に、dbx はシステム生成 SIGSTOP をユーザー生成 SIGSTOP として解釈します。
回避策:
ignore コマンドを使用して、SIGSTOP シグナルを捕獲しないよう dbx に指示します。
スレッドはときどき終了しますが、Linux OS はその終了のことを dbx に報告しません。
あるスレッドが終了し、その終了が報告されなかった場合、dbx は決して発生しないイベントに対して待機し、新しいプロンプトを表示しません。この状況はおそらく、dbx で cont コマンドを入力したあとで発生しますが、step up コマンド、step コマンド、next コマンド、およびその他のコマンドのあとにも発生する可能性があります。
回避策:
Ctrl-C キーを入力すると、dbx が待機を停止して新しいプロンプトを表示する場合があります。
Ctrl-C キーが機能しない場合は、dbx を終了して再起動します。
dbx は、GNU C および C++ コンパイラで次の機能をサポートしません。
VL 配列
例外処理
OpenMP
RTTI
テンプレート定義
デフォルト引数
using 指令
friend
Oracle Linux 6 上の dbx には、いくつかの問題が存在しています。
システムライブラリ内で間接参照シンボルが使用されていると、dbx がブレークポイントを実際の関数にではなくその参照に設定する場合があります。
gcc 4.4.4 コンパイラでコンパイルされたコードをデバッグする場合:
dbx が可変長配列の出力時にハングアップすることがあります。
dbx は、関数のちょうど末尾 (} の行) で停止されると、局所変数を認識できません。
dbx は、-D コンパイルオプションを使って定義されたマクロを認識できません。
この節では、パフォーマンスアナライザツールの既知の問題について説明します。
「呼び出し元-呼び出し先」タブで、切り捨てられたメトリック値が表示される場合があります。
SPARC T4 プロセッサで icache のストール時間が過大評価される場合があります。
OMP タスクと OMP 並列領域の OpenMP Wait メトリックを足し合わせても、<Total> の OpenMP Wait メトリックに等しくなりませんが、これは、最初の並列領域エントリの前に到着したプロファイリングパケットはすべて、どのタスクや領域の OMP Wait 時間としてもカウントされませんが、合計にはカウントされるからです。
実験の追加や削除は必ずしも正しく処理されません。回避方法は、最初にすべての実験をロードし、削除対象の実験をフィルタリングして除外することです。
タブの移動が必ずしも正しく動作しません。
タブ内での項目の複数選択が必ずしも正しく動作しません。
アナライザがときどき SummaryDisp.updateSummary (SummaryDisp.java:249) でハングアップします
「ソース/逆アセンブリ」タブで選択を行ったときに、「概要」タブが更新されません。
ゼロでないメトリックが存在していても、「ソース」タブのマージンの強調表示が表示されない場合があります。
共有オブジェクトの「表示/非表示/API のみ」機能が、フィルタリングと組み合わせた場合に必ずしも正しく動作しません。この問題は、er_print を使用して実験データを表示する場合にも発生します。
「フィルタの管理」ダイアログボックスの「一般」タブで「適用」ボタンを押しても、変更が必ずしも適用されません。「適用」を複数回押すとうまくいく可能性があります。より信頼性の高い回避方法は、「タイムライン」、「スレッド」、および「CPU」データタブのコンテキストメニューからフィルタにアクセスすることです。
「タイムライン」タブで、スレッドや CPU が数値順に表示されないことがあります。
この節では、collect ユーティリティーやデータ収集の既知の問題について説明します。
一部の最適化されたコードで、Sandy Bridge マシン上でのスタック巻き戻しが正しくない場合があります。
JDK 1.7 でのロックアルゴリズムの実装変更のため、Java プログラムの同期トレース時に、すべての Java 同期イベントが二重カウントされます。回避方法は、報告された値を 2 で割ることです。
Linux システム上のマルチスレッドアプリケーションのクロックプロファイリングで、スレッドに関して不正確なデータが報告されます。プロファイルシグナルは、必ずしもカーネルから各スレッドに指定された間隔で配信されるとは限りません。シグナルが間違ったスレッドに配信される場合もあります。可能であれば、より正確なスレッド単位の結果が得られるように、cycle カウンタによるハードウェアカウンタプロファイリングを使用してください。
異なるクロック周波数で動作する複数の CPU を持つシステムのクロックプロファイリングでは、1 つの CPU のクロックレートに基づいてイベントが生成されるため、ほかの CPU 上のイベントが過大または過小にカウントされる可能性があります。
この節では、スレッドアナライザの既知の問題について説明します。
次のすべてが真であれば、スレッドアナライザの実行時エラーが発生する可能性があります。
データ競合を検出するために discover で計測されたバイナリ上で、collect が実行される
その実行が、UltraSPARC T2 のような、ハードウェア機能フィルタをサポートする SPARC プロセッサを備えたマシン上で行われる
マシン上で Solaris 10 Update 9 以前のアップデートが実行されている
問題を回避するには、collect を実行する前に、環境変数 LD_NOAUXFLTR=yes を設定してフィルタライブラリのロードをスキップします。フィルタを使用しないことにより、パフォーマンスが若干低下する可能性があります。
この節では、er_kernel ユーティリティーの既知の問題について説明します。
er_kernel はときどき、実行元のマシンをクラッシュさせる可能性があります。この問題は、UltraSPARC T1、T2、および T2+ チップ上で動作する Oracle Solaris 10 でのみ発生するもので、その原因はハイパーバイザのバグです。
er_kernel プロファイルはときどき、CPU 状態の属性を間違って決定し、ユーザーデータを正しく報告しません。
1 つ以上の CPU が er_kernel イベントの生成を 30 秒以上停止することがあります。
ユーザープロセスの DTrace スタック巻き戻しで 1 つのフレームが省略されることがありますが、それは特に、リーフ関数がその関数プロローグまたはエピローグ内で実行中の場合に発生します。
異なるクロック周波数で動作する複数の CPU を持つシステムの er_kernel プロファイリングでは、1 つの CPU のクロックレートに基づいてイベントが生成されるため、ほかの CPU 上のイベントが過大カウントまたは過小カウントされる可能性があります。
この節では、IDE の既知の問題について説明します。
バージョン管理フレームワークがフルリモートモードで動作しません。(195121)
バージョン管理フレームワークはしばしば java.io.File と関係しながら動作するため、リモートファイルオブジェクトを操作できるプラグインを作成することは不可能です。
回避方法:リモートホスト上のバージョン管理ツールを ssh 経由で直接使用します。
GDB 7.2 が使用されている一部のプラットフォームで、「ステップオーバー」が「継続」として動作することがあります。 (200196)
回避方法:以前の GDB バージョンを試すか、プロジェクトプロパティーの「実行」セクションの「コンソールタイプ」を、「内部ターミナル」から別のオプションに変更します。
メモリーアクセスエラーツールがリモートプロジェクトで動作しません。 (7109562)
リモートホスト上にプロジェクトを作成したあと、そのプロジェクトをメモリー分析用に計測して実行すると、can't execute: discover: No such file or directory というエラーメッセージが表示されます。
「デバッガコンソール」タブをクリックしても、デバッガコマンドのプロンプトにフォーカスが設定されません。 (7102076)
回避方法:コマンドをプロンプトに入力できるように、タブ内でもう一度クリックしてフォーカスを設定します。
バイナリから新しく作成されたフルリモートプロジェクトが「プロジェクト」タブに表示されません。 (7110094)
IDE のデスクトップ配布を実行し、リモートホスト上の既存のバイナリからプロジェクトを作成した場合、その新しく作成されたプロジェクトが「プロジェクト」タブに表示されません。
回避方法:「ファイル」 > 「リモート C/C++ プロジェクトを開く」を選択し、開くプロジェクトを選択します。
SPARC プラットフォーム上のバイナリが認識されないため、バイナリからフルリモートプロジェクトを作成できません。 (7109551)
IDE のデスクトップ配布を実行し、SPARC プラットフォームであるリモートホスト上の既存のバイナリからプロジェクトを作成し、「ファイル」 > 「リモート C/C++ プロジェクトを作成」を選択したときに、バイナリが認識されません。ファイルチューザのフィルタが「すべてのバイナリファイル」に設定されている場合、バイナリが表示されません。フィルタが「すべてのファイル」に設定されている場合は、バイナリを選択できるものの、「バイナリファイルが見つかりません」というメッセージが表示されます。
ここでは、これまでにわかっている 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 または ssh) がパスワードなしで動作し、各リモートログインの所要時間が許容範囲 (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 または ssh を使用できる必要があります。
dmake ソフトウェアがインストールされている bin ディレクトリに構築サーバーからアクセスできる必要があります。デフォルトでは、dmake は構築サーバー上の dmake 実行可能ファイルへの論理パスが dmake ホスト上の実行可能ファイルと同じものであると仮定します。この仮定を無効にするには、実行時構成ファイルのホストエントリの属性としてパス名を指定します。
ホスト上に /etc/opt/SPROdmake/dmake.conf ファイルが存在していて、読み取り可能であり、適切な情報が含まれている。このファイルが存在しない場合は、dmake はこのシステムでジョブを 1 つだけ分散します。
|