🤲🏾 🈶 👨🏻‍💻 Intel®Inspector XE 2013：リアルタイムの自動検証とデバッグ 🍌 🌾 👩🏻‍🤝‍👨🏾

テストとトラブルシューティングは不可欠であり、ソフトウェア開発プロセスの最も興味深い部分ではありません。ルーチンから自分自身を取り除くために、誰もがこのプロセスを自動化しようとしています。また、アプリケーションの機能をテストするために特別な自家製テストが作成された場合、一般的なタイプのエラーの検索は、それらによって常にカバーされるものからはほど遠いです。たとえば、メモリリークやデータの競合など、アプリケーションがチェックされていますか？この記事では、更新されたInspector XE 2013を2つの方法で使用する方法を説明します。

定期的な自動テスト（回帰テスト）の場合
デバッガーとペアになっている問題の原因を手動で検索するには

Inspector XEが必要なのはなぜですか？

Inspector XEは、Intel Parallel Studio XEのコード正当性分析ツールですが、別の製品としても提供されます。その目的は、メモリエラー（リーク、初期化されていないメモリへのアクセスなど）およびストリームの相互作用（データの競合、デッドロックなど）によって引き起こされる問題を検索することです。この場合、問題はそれ自体を証明する必要はありません-潜在的なデッドロック（デッドロック）がある場合、Inspector XEは、プログラムが「ハング」していなくてもそれを見つけます（ただし、発生する可能性のあるコードブランチは実行されています）。

インスペクターは動的分析を使用します。ソースコードではなく、実行可能なプロセスが分析されます。実行中、インスペクターはアプリケーションで発生していること、メモリの割り当てと解放、スレッドの作成、同期オブジェクトの使用などを分析し、その後、見つかった問題のリストをプログラマーに提供します。

別の問題については、ソースビューでさらに詳しく調べることができます。

ソースの静的分析もありますが、Intelコンパイラーによって実行されます。また、Inspector XEは、分析結果を表示、視覚化、フィルタリング、問題のステータス管理などを可能にします。この投稿では、このトピックについては触れません。

ところで、Inspector XEはC / C ++、C＃、およびFortranコードで動作します。 2つのオペレーティングシステムで使用可能：Windows *およびLinux *。どちらにも、GUIとコマンドラインの2つのインターフェイスがあります。さらに、WindowsではMicrosoft Visual Studio *にも統合されます。

原則として、実行可能ファイルはすべて検査できます。ただし、問題を検出する可能性を高め、ソースコードでそれらを確認し、あまり時間をかけないために、いくつかの推奨事項があります。

/ MDd、/ ZI、/ Odスイッチでコンパイルし、/ DEBUGおよび/ FIXED：NOでリンクします（Microsoftコンパイラーとリンカーを例として使用）。多数のバイナリとソースコードにはシンボリック情報が必要であり、Inspector XEがコンパイラによって混乱しないように最適化をオフにする必要があります。
マルチスレッドエラーを見つけるには、可能であればアプリケーションの負荷を減らします。たとえば、入力のサイズを最小化します。これは時間を節約します Inspector XEは、プログラムの速度を低下させます-動的分析とバイナリ計測のコスト。検査官はフローの相互作用で潜在的な問題を探しているため、負荷を減らしても結果には影響しません。
それどころか、メモリエラーを検索するには、完全なデータセットを使用することをお勧めします。このタイプのエラーでは、実際の問題が検出されます。
コードのさまざまなブランチをアクティブにするテストを選択します。コードブランチが実行されない場合、解析されません。

自動テスト

Inspector XE-検証ツール。また、ソフトウェアの品質と安定性を高いレベルで維持するために、検証を定期的に実行する必要があります。たとえば、夜間の回帰テスト中にインスペクターを実行できます。これを行うには、ツールのコマンドインターフェイスを使用します。 Linux *とWindows *のInspector XEコマンドの構文は同じです。 Windowsでテストアプリケーション分析を開始する例：

inspxe-cl -collect mi3 -knob resources=true -knob still-allocated-memory=true -knob stack-depth=16 -knob analyze-stack=true -- D:\tests\testapps\mem_error.exe

コマンドラインは常にインスペクター自体で始まります-「inspxe-cl」。「-collect」キーは、分析を実行する必要があることを示し、「-mi3」-分析のタイプ（メモリエラーの検索、または「メモリの問題の特定」）。さらに、分析の他のパラメーターと分析されたアプリケーションへのパスがあります。コマンド「inspxe-cl -help」を使用して、完全な構文とパラメーターのヘルプを印刷できます。さらに、GUIで既に作業しており、コマンドラインで同じ分析を実行する場合は、GUIで構成された分析の既製のコマンドラインを形成する「コマンドライン」ボタンがあります。

分析が完了すると、Inspector XEは結果ファイルを含むフォルダーを作成します。これらはGUIで表示でき、Linuxで収集された結果は別のWindowsマシンで表示できます（逆も同様です）。ただし、単純にスクリプトから分析を開始し、結果を手動で表示することは完全な自動化ではありません。したがって、インスペクターには、検出された問題に関する情報とCLIの情報を出力する機能があります。

 inspxe-cl -report problems -r D:\tests\testapps\r002mi3

 P1: Error: Mismatched allocation/deallocation New Problem P1.1: Mismatched allocation/deallocation D:\tests\testapps\mem_error.cpp(48): Error X10: Allocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp(49): Error X9: Mismatched deallocation site: Function start: Module D:\tests\testapps\mem_error.exe P3: Error: Invalid memory access New Problem P3.1: Invalid memory access D:\tests\testapps\mem_error.cpp (40): Error X4: Allocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp (42): Error X5: Deallocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp (44): Error X3: Read: Function start: Module D:\tests\testapps\mem_error.exe

プレーンテキストが適切でない場合は、csvにエクスポートするか、XML形式で印刷して、あらゆる種類のPerlおよびPythonで解析できます。

 inspxe-cl -report problems –format=xml -r D:\tests\r002mi3\

 <?xml version="1.0" encoding="UTF-8"?> <pset id="P1" type="Mismatched allocation/deallocation" state="New" severity="Error"> <obs id="X1" type="Allocation site" state="New" severity="Error"> <stack id="10"> <frame id="" module=" D:\tests\testapps\mem_error.exe" file="D:\tests\testapps\mem_error.cpp“ func="start" line="48"/> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start1" line="84"/> <frame id="" module="C:\Windows\syswow64\kernel32.dll“ func="BaseThreadInitThunk" line="78792"/> </stack> </obs> <obs id="X2" type="Mismatched deallocation site" state="New" severity="Error"> <stack id="9"> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start" line="49"/> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start1" line="84"/> </stack> </obs> </pset>

大規模プロジェクトで非常に多く見られるさまざまな問題から、新しく注目すべき問題を除外する必要があります。 Inspector XEには、問題にステータスを割り当てる機能があります（新規、確認済み、修正済みなど）。プロジェクトを定期的に検査する場合、ダイナミクスは主に興味深いものです。最近の変更以来、何か新しいものはありませんか？この場合、Inspector XEは、異なる起動からの問題に関する情報を組み合わせて、変更の要約を提供できます。

 inspxe-cl –merge-states D:\tests\r000mi3\ -r D:\tests\r001mi3\

 inspxe-cl -report status -r D:\tests\r001mi3\

 9 problem(s) found 3 Investigated 6 Not investigated Breakdown by state: 2 Confirmed 1 Not a problem 4 Not fixed 2 Regression

Inspector XEは、潜在的な「マルチスレッドエラー」を見つけるのに非常に役立ちます。データの競合を伴う単純なC ++の例を考えてみましょう。ループはOpenMPを使用して並列化されます。反復スペースは小さな部分に分割され、並行して実行できます。

 #pragma omp parallel for shared(j) for(i=0; i<MAX; i++) { printf("j=%d ", j++); } if(j != MAX) printf(“error\n”);

このレースが時々現れるためには、MAX> 100,000,000を使用する必要があり、テストは10分以上かかりました。 Inspector XEは、MAX = 10および10秒でこのような問題を検出します。潜在的なデータ競合を探しています。もちろん、この例は非常に洗練されていますが、説明のために使用できます。このような場合、検査官はテスト実行の有効性を高めます-単位時間あたりにより多くの問題が見つかります。

検索を絞り込むために、いくつかのアプリケーションモジュールのみを分析できます。

 inspxe-cl -collect mi1 -module-filter module1.dll,module2.dll -module-filter-mode exclude -- D:\tests\testapps\mem_error.exe

「-module-filter-mode」パラメーターは、指定されたモジュールを分析から除外する（除外）か、その逆の場合、それらのみを分析する（含める）かを決定します。

子プロセスを分析する必要がある場合-たとえば、アプリケーションがスクリプトから起動される場合、「-executable-of-interest」オプションを使用します。

 inspxe-cl -collect mi1 -executable-of-interest mem_error.exe -- D:\tests\testapps\startup_script.bat

検査官から得られた結果は、異なるチームメンバーによって使用される場合があります。結果を転送するには、「エクスポート」オプションを使用します。結果をいくつかのソースとともに1つのアーカイブにパックするため、別のマシンではプロジェクト、ファイルパスなどを構成する必要はありません。

 inspxe-cl -export -archive-name my-new-archived_result.inspxez -include-sources -result-dir myRes

チームワークには、次の場合にも役立ちます。

問題に関するテキストレポートとコメントを作成する機能
異なるユーザーによる結果の同時編集に対する保護
一般的な抑制ルール。たとえば、インスペクターが外部モジュール（システムライブラリ）で修正する予定のない問題を見つけた場合、それを明確にマークすることができます-結果を詰まらせないように抑制します。抑制ルールは、チーム全体に共通の特別なファイルに保存されます。

それだけです現在、Inspector XEの起動と解析結果の解析を、夜間テストを実行するスクリプトに統合することは残っていますが、これはすでに個別であり、この投稿では取り上げていません。

インスペクター+デバッガー= 2つのスチームブート

Inspector XEを使用するもう1つのモデルは、問題を手動で検索して問題の最下部に到達することです。おそらくプログラムには何らかのバグがあります-時々フリーズまたはクラッシュします。または、検査官による毎晩のテストで、対処する必要がある新しい問題が発見されました。または、座って作成の信頼性をもう一度確認することにしました。

これらの場合、Inspector XEをデバッガーと統合すると役立ちます。この機能はそれほど前ではなく、バージョン2013で登場しました。現時点では、Linux上のgdbおよびIntel DebuggerデバッガーとWindows *上のVisual Studio Debuggerとの統合がサポートされています。

不明な問題（アプリケーションの一部にバグがある場合）を探している場合は、分析設定で[問題が検出されたときにデバッガーを有効にする]を選択して、デバッガーと共にインスペクターを起動します。

ここで、分析を開始して待機します。問題が検出されるとすぐに、Inspector XEは実行を停止し、デバッガーで掘り下げることができます。これは、見つかったすべての問題に対して実行されます。

夜間のテスト中に明らかになった何らかのバグをすでに狙っている場合は、インスペクターで分析結果を開き、問題を右クリックして「この問題をデバッグ」を選択します。 Inspector XEは同じ分析を再び開始し、指摘された問題が再び現れるとすぐに、発生した場所でデバッグセッションに没頭します。

ブレークポイントを設定し、3番目のオプションを選択して、インスペクター分析構成でデバッガーを開始することもできます。

この場合、Inspector XEは、このブレークポイントで実行が停止するまで何も分析しません。また、[デバッグ]メニュー（Visual Studio）で[Inspector XEで続行]を選択すると、実行は継続されますが、検査は行われます。その後、すべてが最初のシナリオに従って進み、見つかった問題ごとに停止します。これは、分析時間を短縮し、このコンテキストで重要ではないコード（たとえば、長い初期化）を除外するために役立ちます。

まとめ

Inspector XEは、メモリエラーとマルチスレッド実行を見つけるための汎用ツールとして機能します。動的分析により、かなり複雑で、根深い問題を検出できます。そのため、分析中のプログラム実行時間は大幅に増加する可能性があります。 Inspector XE 2013は、GUIでの作業、トリッキーな問題の根本原因の発見に役立つデバッガーとの組み合わせ、および自動検証の両方に使用できます。ただし、どちらの場合も、コードの安定性を高めるのに役立ちます。問題が多くなり、これが早く行われるほど、完成したアプリケーションの信頼性が高まります。

Intel Inspector XE

Intel Parallel Studio XE 2013

Inspector XE 2013ドキュメント

Intel®Inspector XE 2013：リアルタイムの自動検証とデバッグ

Inspector XEが必要なのはなぜですか？

自動テスト

インスペクター+デバッガー= 2つのスチームブート

まとめ

More articles: