Comments
Description
Transcript
レアなバグをあぶり出す - Tingting Yu 氏インタビュー
レアなバグをあぶり出す - 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-tingtingyu.html 本社ブログサイト：http://blogs.windriver.com/