Reproducing Concurrency Failures from Crash Stacks

著者/所属機関

Francesco A. Bianchi (Universit della Svizzera italiana) et al.

出典

ESEC/FSE 2017

目的

並行バグを再現するテストコードの自動生成

問題

• 並行バグ再現に関する既存手法は下記の2つに分類されるがそれぞれ問題あり + いずれもテストコードの生成まで扱ってない
  1. Record & Replay: 実行時に命令列を記録して再現
  • オーバーヘッドが大きく本番環境への導入障壁高
  2. Post-processing: ログなどの情報を後で解析して再現
  • 既存手法はメモリダンプなどが対象で収集コストが大きい
  • あるいは通常扱ってない専用の情報を必要とするため導入障壁高

解法

• 対象のソースコードとクラッシュ時のStack Traceを入力に，当該クラッシュを引き起こすテストコード生成技術の提案
  • ノードを実行状態，エッジを次に実行する命令とする木構造を構築し，クラッシュ時と同様のStack Traceを再現する命令列を探索
  • Stack Trace再現に不要な探索空間を削減する枝刈り手法を提案
    • どうやってもStack Traceを再現できないことがわかった時点で探索打ち切り，過去に同様の命令列を探索していたら打ち切り，など
  • inerleavingの探索は既存手法 Cortex¹を利用

“A Tree Model” from Author’s dissertation

結果

• 5つのプロジェクト(Commons DBCP, Commons Math, Java JDK, JFreeChart, Log4j)で実際にあった並行バグとバグが発生したクラスを対象に実験

RQ1: 並行バグを再現する際の効率は?

• 提案手法で全バグを再現できた
• 全体平均で46秒，最長で185秒でバグ再現できた

RQ3: 他の手法と比べた性能は?

• 2つの既存手法を試したところ，18%～28％のバグしか再現できない
  • 既存手法は特定の種類のバグにだけ有効
  • 提案手法は種々のバグに対応可能

Tagged: #concurrency