レアなバグをあぶり出す - Tingting Yu氏インタビュー
投稿者：Jakob Engblom, 2012/05/02
Simicsを使えば、ターゲットのソフトウェアでエラー状態を強制的に起こせます。これはSimicsの素晴らしい使い方の1つです。Simicsのようなツールには、元々、ハードウェアの状態管理を可能にする特性があり、予想される共通のパスでシステムをノックオフし、あまりテストをしていないコードを走らせ、非常に稀な状況でしか発生しえないバグをあぶり出すことができます。そのようなSimicsの応用方法を議論した論文が最近発表されました。今回のブログでは、ネブラスカ大学リンカーン校（UNL）のTingting Yuさんにこの論文について伺います。
ヤコブ・エングブロム（JE）：まず自己紹介をお願いします。
Tingting Yu：Tingting Yuです。ネブラスカ大学リンカーン校のコンピューター・サイエンスおよびエンジニアリング学部の博士課程に在籍しています。ESQuaRED（実験に基づくソフトウェア品質に関する研究開発）ラボのメンバーです（http://esquared.unl.eduを参照). Dr. Gregg Rothermel とDr. Witawas Srisa-anから指導を受けています。
JE：研究グループで扱っている内容は。
TY：ESQuaReDは、ネブラスカ大学リンカーン校のソフトウェア工学グループの1つで、UNLのコンピュータ・サイエンスおよびエンジニアリング学部に属しています。現在、グループには大学院生30名と、教職員6人がいます。 国際的なソフトウェア・エンジニアリング関係学術者の最新ランキングでは、当学部の教員であるGregg Rothermel、Matt DwyerとSebastian Elbaumの3人が、世界の上位50人に選ばれました。
JE：研究トピックは何ですか。
TY：私の主な研究分野は、ソフトウェア試験です。テスト手法の設計による組込型システムや並列処理プログラムなどの高度なソフトウェアにおける信頼性の向上を目指しています。
組込型システムのシステム・レイヤー間（アプリケーション、OS、HAL/BSP）での操作違反をテストするための十分性テスト条件を開発しました。また、アウトプット・ベースのテストオラクルでは検出できない障害を特定するため、プロパティ群ベースのテストオラクルを提案しました。こうしたシステムのテストを実施する際の可観測性と制御性の改善を目指した、SimTesterというテスト・フレームワークを開発中です。これは、仮想マシーン（VM）の既存の特性を活かしプロパティ・ベースのテストオラクルを生成し、ハードウェアの中断やマルチスレッド、メモリー・アクセス等による「観測が難しい」障害を検出するものです。SimTesterではさらに、非決定的な問題に対応できる粒度の細かい制御性（障害露出の可能性を高めるハードウェア・イベントのコントロール）を実現します。
JE：ということは、テストオラクルは、必ずしもアウトプット・エラーとして宣言されないシステム内の問題を検出するために使えるということですか。
TY：テストに関する文献では、テストオラクルは、テストケースがシステム内での障害を導き出せたか否かを判断するデバイスである、とされています。テストオラクルは、プログラムのアウトプットと内部ステートの両方の問題を検出可能です。
私たちが利用しているテストオラクルは、アウトプット時にシステムの内部ステートとして必ずしも宣言されない問題の検出に重点を置いています。例えば、データレースが発生した場合に、アウトプットに必ずしもエラーが出るわけではありません。あるスレッドが優勢となり、別のスレットが書いたデータを完全に上書きしてしまうことも考えられます。そうすると、これらの2つのスレッドは同一のデータを書き込んだことになります。しかし、別のインターリービングがデータ破損を起こし、アウトプットにエラーを伝播してしまう可能性もあります。VMにアクセスするデータをモニタリングし、内部のオラクルを使うことで、エンジニアは具体的なインターリービングやインプットデータを待つことなく、効果的に障害を検出できます。
JE：Simicsをどのように活用しましたか。
TY：ソフトウェアとハードウェアのインタラクションで発生する並列処理の障害を検出する際にSimicsを使っています。Simicsを使うことで、障害の検出に求められる可観測性と制御性を実現できます。仮想システムのステートに影響を与えることなく実行処理を中断でき、関数の呼び出しや変数値、システムの状態をモニタリングし、ハードウェアに中断やトラップなどのイベントを強制させることが可能です。
つまり、SimTesterは肝心なところでシステムの実行を止め、従来からの非決定的なイベントを強制的に発生させることができるのです。その後、SimTesterを使ってシステム上でのイベントの有効性をモニタリングし、異常の有無を判断します。例えば、アプリケーション間のデータレースを検出しハンドラーを中断するために、Simicsのメモリー・ブレークポイントを設定し、共通の変数アクセスをモニタリングしています。また、ハードウェア中断のピンステータスに直接変更を加え、アプリケーション内で共通の変数にアクセスされた場合に特定の中断が発生させることで、データレースを特定する可能性を高めています。
JE：それは素晴らしいですね。実際のハードウェアでは断続的で非常にまれなバグを誘発させるためにSimicsを使っているということですね。また、自明でないバグが発生したときに検出できる、と言う点も重要ですね。
TY：はい、そのような動きをしてくれます。Simicsに加えて、以下の通り、主要なコンポーネントが4つあります。テストオラクル以外のコンポーネントはすべて、Phythonスクリプトを使っているため、SimicsはPythonスクリプトでアクセスするためのAPIを提供します。
コンフィギュレーション・スクリプトは、メモリー・ブレークポイントや、モニタリング対象の変数のアドレス、モニタリング対象のマシーン・インストラクションなど（例えば、iret、すなわち割り込みリターン命令）を設定する場所を具体的に示します。
エクゼキューション・コントローラーは、プログラム実行時の特定の地点で、特定のハードウェア・イベントを呼び出すよう指定します。また、デバイス・ポートにデータを入れ、中断ハンドラーとして別のパスを通るよう強制できます。中断を強制する前に、その中断処理を発行することで、異常な中断を回避できるか否かを、エクゼキューション・コントローラーがハードウェアに対してチェックします。
エクゼキューション・オブザーバーが、情報をモニタリングし生成します。この情報とは、ファイルに記録してオフライン分析を実施できる、またはテストオラクルに直接入れてオンライン分析が可能なものです。テストに関する文献では、テストオラクルは、テストケースがシステム内での障害を導き出せたか否かを判断するデバイスである、とされています。異常はすべて、結果ファイルでレポートされます。
JE：つまり、シミュレーターを使ってターゲットをコントロールし、問題を起こす可能性のある時点で中断のような非同期のハードウェア・イベントを出すということでしょうか。
TY：Simicsは、計測やその他のツールにサポートせずに、重要なポイントで中断を発生させるように直接ハードウェアの状態を操作できるAPIを提供しています。
JE：テストケースはどのように設定していますか。
TY：コード・カバレッジ・ベースのテスト十分性条件を基にテストケースを作成しています。対象地点に応じて、障害タイプごとに異なるカバレッジ基準を設けています。例えば、レース条件に合ったテストケースを生成するには、アプリケーションと中断ハンドラー間で共通の変数を統計的に特定しています。その後、共通の変数と思われる内容をカバーしたテストケースをマニュアルで作成します。
デッドロックに合わせたテストを作るには、lock acquireのオペレーションをカバーするテストケースを生成します。そうすることで、プログラムのすみずみまでカバーして障害を検出できます。テストケースを作るプロセス自体は、ダイナミック・シンボリック・エクゼキューションなどテクニックで自動化も可能です。
JE：このアプローチに最も適したバグはどういうものだと思いますか。
TY：シーケンシャルと並列、両方のプログラムのあらゆる種類の障害を検出する目的で、このテスト・フレームワークを作っています。しかし、既存のランタイム・チェック・ツール（valgrindやpacerなど）を使って、ユーザー・アプリケーション単位で障害を検出するものもありますが、私たちのアプローチは、OSやハードウェアへの依存度が高いタイプの障害を対象としています。例えば、コードの測定などでは観測、制御しにくい障害です。
ここまでのところ、linuxデバイス・ドライバーでデータレースやデッドロックに関連した実際の障害を検出できています。
このアプローチでは、Simicsによってユーザーがメモリを観測し操作できる強力なインターフェースが提供されているため、バッファー・オーバーフローや、メモリー漏れなどの検出にも優れています。
JE：より詳しい情報はどこから入手できますか。
TY：私どもがVEE2012で発表した論文「SimTester: a controllable and observable testing framework for embedded systems」をご覧ください。何か質問やコメントがあれば、Emailで私までご連絡ください。
原文はこちら：http://blogs.windriver.com/tools/2012/05/forcing-rare-bugs-to-appear-an-interview-with-tingting-yu.html
本社ブログサイト：http://blogs.windriver.com/
