インテル® Inspector

サポート

• コミュニティーに問い合わせ

  Forums (英語) からほかのユーザーやエキスパートに問い合わせできます。

• インテル社の製品サポートに英語で問い合わせ

  Online Service Center (英語) ではインテル社のサポートチームにお問い合わせいただけます。

• エクセルソフト社の技術サポートに日本語で問い合わせ

  ユーザー登録完了後、技術サポート受付フォームよりお問い合わせください。

ドキュメント

• 導入ガイド (英語)
• チュートリアル (英語)
• インテル® Inspector ユーザーガイド [Windows* (英語) | Linux* (英語)]
• インテル® Inspector リリースノート (英語)

ソフトウェア EULA (英語)

すべて開く すべて閉じる

よくある問い合わせ

1. インテル® Inspector XE を使用するには、プログラムを再コンパイルしてリビルドする必要がありますか?

   いいえ。インテル® Inspector XE のメモリーチェックとスレッドチェックは、インストルメント・ベースでプログラムのバイナリーを動的に解析します。プログラムの再コンパイルやリビルドの必要はありません。エラーレポートがソースコードの位置を参照できるよう、デバッグバイナリーもしくはデバッグ情報付きのリリースバイナリーを使用することをお勧めします。

2. インテル® Inspector XE は、すべてのメモリーとスレッド化のエラーを検知できますか?

   インテル® Inspector XE の最高レベルの解析を行うと、アプリケーションのコードパスに存在するメモリーやスレッドエラーを検出できる可能性は高いですが、すべてのメモリーおよびスレッドエラーを検出するという保証はありません。

3. インテル® Inspector XE のスレッドチェック解析とメモリーチェック解析は、異なるプロセスで実行されますか?

   いいえ。実行時に対象のプログラムのアドレス空間に埋め込まれます。

4. インテル® Inspector XE は、実行中のプログラムをアタッチしたりデタッチすることはできますか?

   いいえ。現在のインテル® Inspector XE は、プロセスのアタッチとデタッチをサポートしていません。アプリケーション・プロセスのマルチスレッド化のバグを検出するには、インテル® Inspector XE は、プログラムの開始時からメモリー初期化イベント (メモリーチェック) や同期イベント (スレッドチェック) をモニターする必要があります。もちろん、インテル® Inspector XE の解析を手動で開始し、いつでも停止することができます。

5. インタラクティブなデバッグ機能とは何ですか?

   インテル® Inspector XE のインタラクティブ・デバッグ機能は、検出されたメモリーやスレッドの問題を調査するため標準的なデバッガーを使用することを可能にします。Windows* 環境では Microsoft* Visual Studio* 2010 – 2015 デバッガーが、Linux* 環境ではインテルおよび GNU* デバッガーがサポートされます。

6. 簡単に解析を開始してデバッガーにアタッチすることはできますか?

   それは簡単ではありません。インテル® Inspector XE は、アプリケーションのバイナリーをランタイムで解析します。これは、解析するのはアプリケーション・コードだけではないことを意味します。これにデバッガーをアタッチすることはできますが、多くの時間を費やす解析ツールのコードを見ることになり、ツールがアプリケーション・コード中でレポートする問題に関しては何も情報を得られないでしょう。

7. インテル® Inspector XE がコード位置の問題レポートを生成した時に、解析セッションと同時にデバッグを行いたいのですが (通常デバッガーの配下でアプリケーションを実行することができ、ブレークポイントを設定できます)。

   メモリーやスレッド解析を行わずデバッグを行うと、コードのブレークポイントで適切に実行を停止できますが、その場所は問題が報告される前に正常に数千回も実行されているかもしれません。解析とデバッグを組み合わせることで、ツールが問題の発生条件を認識すると、適切なタイミングで、コード位置に停止し作業を継続できます。

8. 解析中にデバッグを行うことはできますか?

   解析中にデバッガーを利用する主な理由は、インテル® Inspector XE によって報告された特定のメモリーやスレッドの問題のコールスタックと周辺のコードを調査した後に、アプリケーションの変数の内容や他のスレッドの振る舞いのような原因を特定するためより多くの情報が必要になるためです。多くの場合、解析を軽減できることから、注目する問題の “Debug This Problem” を選択すると可能な限り迅速にそのポイントに戻ります。

   多くの開発者は、実行に長い時間がかかり除外オプションが希望する粒度のレベルを保証していないアプリケーションの特定のセクションのエラーをチェックしたいと思うでしょう。コードにブレークポイントを設定して解析をオフにして実行を開始することで、エラーチェックの対象とするモジュール内の特定の位置までの実行時間を大幅に短縮できます。スレッドのエラーをチェックする際、解析の対象とするコード領域が全体の実行時間と比較して非常に小さい場合、この手法は効果的です。スレッド解析の最適化は、実行速度を極度に低下させるデバッグを有効にした解析と同時に行うべきではありません。デバッグなしで完全な解析を行うと、解析する領域を制限するデバッグを有効にした方法よりも高速に実行できます。メモリーエラーのチェックにはこの問題はありません。

   アプリケーションのメモリーエラーを初めて解析し、報告される各問題でデバッグを行いたい場合、デバッグを有効にして解析を始めると良いでしょう。各メモリーの問題が検出されると解析を停止し、デバッガーでプログラムの問題を調査するか、実行を継続できます。一般に、前述のようにデバッグ時の解析の最適化は、速度の問題から行うことができず、スレッド解析にこの手法を導入すべきではありません。

9. スレッドチェック機能は、プログラム中の潜在的なエラーを検出することはできますか?

   これは、潜在的なエラーの範囲に依存します。スレッドチェック解析は動的であり、実行されたコードのエラーのみを検出できます。つまり、実行されなかったコード中のエラーを見つけることはできません。スレッドチェックでは、実行されたコード中のデータ競合、スレッド間のスタックアクセス、およびデッドロックの可能性などの潜在的なエラーを見つけることができます。これが、プログラムが正しい結果を生成していても、スレッドチェックがプログラム中のエラーをレポートすることがある理由です。

10. スレッドチェッカーは、プログラム内のアトミック性違反などの論理エラーを検出できますか? 例えば、同じクリティカル・セクションになければならない 2 つのメモリーアクセスが、異なるクリティカル・セクションから行われた場合です。

    いいえ。現製品のスレッドチェッカーは、アトミック性違反などの論理エラーは検出できません。

11. 並列プログラミングにおいて、スレッド (もしくはメモリー) 解析は並列に実行に動作しますか? 言い換えると、解析は利用可能なマルチコア・ハードウェアを利用していますか?

    はい。メモリーチェッカーとスレッドチェッカーは両方とも、利用可能なコアや並列プログラムで利用されるハードウェア・スレッド上で解析を行います。一般的に、解析のオーバーヘッドはうまくスケールし、アプリケーションのスケーリング係数と同じです。

12. スレッドチェックはマルチコア・マシン上で行わなければいけませんか? 開発にはシングル・プロセッサーのシングルコア・マシンを使っています。このシングルコア上でスレッド化のバグを検出できますか?

    インテル® Inspector XE は、シングルコアのマシン上でもスレッド化のエラーを検出する機能を持っています。そのため、マルチスレッド・アプリケーションであってもマルチコア・マシン上で実行する必要はありません。プログラムが、Windows* や POSIX* のスレッド API によって明示的にスレッドを生成している場合、シングル・プロセッサーやシングルコア・マシンで複数のスレッドを生成しても問題はありません。プログラムが、インテル® スレッディング・ビルディング・ブロック (インテル® TBB)、OpenMP* 、インテル® Cilk™ Plus、もしくはほかのタスクやスレッド化モデルを使用する場合、通常マシン上で利用可能なコア数を基にスレッドを生成するため、複数のスレッドを生成するにはスレッドモデルに強制する必要があります。

    もちろん、マルチコア・マシンを利用する場合、より高いパフォーマンスを得られます。

13. 開発にサードパーティーのコードを使用しています。インテル® Inspector XE は、サードパーティーのバイナリーを除外して、自分のコードのみに焦点を当てることはできますか?

    はい、スレッドチェックやメモリーチェックを行う際に、GUI やコマンドラインで除外するモジュールを指定できます。

    しかし、これはメモリーチェックでは推奨されません。初期化されていないメモリーや不正なポインターは、サードパーティーのライブラリーへ渡される可能性があり、それらが除外されると問題を検知できないためです。そのような場合、問題はサードパーティー・ライブラリーにはありません。

14. サードパーティーのモジュールを解析する気はなく、それらの問題を非表示にしたい。サードパーティー・ライブラリーの問題を非表示にできますか?

    はい、抑制ルールを作成することでそれらを非表示にできます。プロジェクトを継続して解析するため、インテル® Inspector XE は、それらのバイナリーを解析しますが、該当モジュール内で検出された問題をレポートしません。

    [Code Locations] ペインのコンテキスト・メニューの [Suppress …] アイテムをクリックして、GUI から新しいルールを作成します。大きな問題セットに同じルールを適用するため、チェックボックスを選択することができます。

    既存の抑制ルールは、インテル® Inspector XE の [Project Properties] > [Suppressions] タブで確認できます。

    また代替手段として、サードパーティーのモジュールを解析対象から完全に除外することができます。サードパーティーのモジュール解析を除外すると、パフォーマンス上の利点もあります。しかし、サードパーティーのモジュールを除外することは、前述の理由により推奨されません。

15. プラグインモジュールを開発しています。どのようにしてインテル® Inspector XE で解析を行えますか?

    プラグインモジュールを解析するには、プラグインモジュールをロードして実行するアプリケーションをインテル® Inspector XE の下で実行する必要があります。プラグインモジュールのみを解析するのであれば、インテル® Inspector XE のモジュール・インクルードやエクスクルード・オプションを利用できます。

16. 独自の同期もしくはメモリー管理 API を使用しています。インテル® Inspector XE を利用できますか?

    カスタムメモリー管理 API やカスタム同期プリミティブを含むアプリケーションを解析する場合、アノテーションが追加されないと、インテル® Inspector XE は偽陽性をサポートします。

    インテル® Inspector XE は、カスタム同期およびメモリー管理 API の解析をソースコードで通知するため、いくつかの API を提供します。

17. メモリーチェック機能は、プログラム中の潜在的なエラーを検出することはできますか?

    いいえ。メモリーチェックは、プログラムの解析実行中に発生したエラーのみを検出できます。