BugRedux: Reproducing Field Failures for In-House Debugging

Wei Jin and Alessandro Orso

1

目的と問題

目的：出荷後に報告された欠陥を，社内で再現したい

2

問い2: クラッシュレポートはどんな実行時情報を含むべきか？

多くの情報 (e.g., 実行トレースすべて) - 実行時オーバーヘッド大 - プライベートな情報を含んでしまう恐れ

少ない情報 (e.g., 発生した例外の種類のみ) - 報告された欠陥が再現できない

トレードオフ

問い1: どうすれば報告された欠陥を再現できる？

提案ツールと貢献

3

• 実行時情報を収集し，それを利用して

欠陥を再現するツールBugReduxの開発

• 収集する情報を変化させて，費用対効果を調査

欠陥を再現する テストケース生成

提案ツール動作図 発表論文より引用 (日本語は発表者)

ログ関数 埋め込み

報告された欠陥の再現

4

クラッシュレポート中の文をゴールの列とし， ゴールを同じ順番で通過する

欠陥の再現 :=

1. プログラムを記号的に実行． 次に通過したい文に近づくように探索 2. 得られた条件を満たす入力を制約ソルバで求める

クラッシュレポートに含める情報

5

以下の４種類を考慮し，実験的に評価

欠陥を再現するためには どんな情報を記録すべきか？

• 例外発生時の位置(POF) • 例外発生時のコールスタック(Call Stack) • 例外発生時の関数呼び出し履歴(Call Sequence) • 完全な実行トレース(Complete Trace)

実験結果1: オーバーヘッド

6

• POFとCall Stackはクラッシュレポートに入っているのが一般的， オーバーヘッドはほぼ無視できる程度 • Call Sequenceは時間・空間ともにオーバーヘッドがあるが， 完全なトレースよりは桁違いに小さいオーバーヘッド

時間オーバーヘッド(%) 空間オーバーヘッド(kB)

対象とした プログラム達

実験結果2: 欠陥再現性能

7

• POF, Call Stack, Call Sequenceまでは，情報が増えるほど， 欠陥再現の性能が高くなっている • 完全な実行トレースを再現しようとすると， 制約が複雑になりすぎるためか，テストケース生成に失敗した

テストケース生成にかかった時間 欠陥がただしく再現できたかどうか(Yes or No)

対象とした プログラム達