f05: debugging

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

F05: Debugging眞鍋雄貴，石尾隆

大阪大学

※ 論文リストでの表記順序と，発表順序は異なりますのでご注意ください

Partial Replay of Long-Running Applications論文著者： Alvin Cheung, Armando

Soloar-Lezama, and Samuel Madden (MIT CSAIL)

担当者：眞鍋雄貴（大阪大学）

背景・目的• プログラム実行の再現

– プログラムを実行する時にログを記録し，そのログを用いてプログラムの実行を再現する

– バグを起こしている正確な位置を調べるのに用いる• 問題点

– 通常の実行時に大きなオーバーヘッドがかかる– 非常に大きなログを生成してしまう

• Symbolic execution を用いてオーバーヘッドを削減する手法– ログをとる部分を減らす– 足りない部分を Symbolic execution で実行することで補足し，オー

バーヘッドを減らす• 既存の手法は実行の最初から再現するため，現状のSymbolic execution

エンジンでは何か月も動くようなプログラムの実行を再現できない

⇒実行の途中から部分的にリプレイできるようにする3

主な貢献• プログラムの実行の途中から再現するプログ

ラム実行の再現手法を提案• 提案手法を用いたデバッガ（bbr）を実装し

た．

• 特徴– チェックポイントを設定

• ある特定処理に設定したり，パラメータによる設定も行える

– ログは最後のチェックポイント到達時点から，プログラムが停止するまでの部分だけ残す• チェックポイントに到達したとき，そ

の時点の状態をスナップショットとして取る

– ログとスナップショットに基づき．Symbolic executionを用いて，チェックポイントから実行を再現する

ログを残す部分

Symbolic executionによる再現

スナップショット

時刻

チェックポイント到達

通常の実行

C Cプログラム停止

記録するもの

• ログとして–条件分岐の値• 分岐をどう進んだかが決定的に定まる

–アクセスされた配列のインデックス• スナップショットとして–その時点でのスタック–開いているファイルの状態

評価• 目的：オーバーヘッドとログの圧

縮効果の測定• 手法 :6 個のアプリケーションの実

行を対象に，提案手法と他のログの取り方との間で実行時間とログサイズを比較する．

• 結果– オーバーヘッドは平均

10%(1~33%) で他より小さい– ログも他の手法より小さい

• その他の実験結果から，提案手法によりデバッグできることも示されている (4.2 節 )

図は Cheung et.al., “Partial Replay of Long-Running Applications” p141 より

Fault Localization for Data-Centric Programs

論文著者： Diptikalyan Saha, Mangala Gowri Nanda, Pangaj Dhoola, V. Krishna Nandivada,

Vibha Shinha(IBM Research-India) , Satish Chandra(IBM T. J. Watson Research Ctr)

担当者：眞鍋雄貴（大阪大学）

背景・目的• 目的：ABAP で記述されたデータ

中心プログラムに対するプログラムエラーの高速な解決の支援– ABAP ：SAP-ERPで使用され

る手続型＋宣言型言語– データ中心プログラム：デー

タベースなどにある大規模なデータ集合を処理する

• プログラムスライスを用いた欠陥の局所化– ある変数について正常な値と，

異常な値をとる場合，それぞれの場合におけるスライスの差分に欠陥がある可能性が高い

– 本研究では動的スライスを用いる 8

図は Saha et.al., “Fault Localization for Data-Centric Programs” pp.157 より

データ中心プログラムにおける問題

• 従来の field-row sensitive な動的スライスではデータベースの要素の追加削除が起こったとき，スライス基準に影響を与えうるかわからない– キーの値によっては影響が出な

いことがある⇒ キーとその値を考慮する

• データ中心プログラムでは，従来の実行系列に基づく差分検出では差が出ない場合がある⇒ 実行時の振る舞いの差異を考慮する

9図は Saha et.al., “Fault Localization for Data-Centric Programs” pp.158 より

主な貢献• Key based Slicing

– 従来の field-row sensitive な動的スライスアルゴリズムに， key-value pair の集合を入力とする，データベースへの変更が key-value pair と関係があるかを調べる処理が追加された動的スライスアルゴリズム

• Semantic Difference– Corner-case Differences: 実行された各文について，特殊な

状況が起こっているかどうか• 特殊な状況は各文の種類に対して設定されている

– Mutation Differences: 正常系のスライスに影響を与えないよう，異常系のスライスが正常系のスライスと同じふるまいになるようにするにソースコードを変異させたとき，その変異部分

• 提案手法により，出力における行の欠落もわかる

評価• 目的：Key based slicing, Semantic diff, 出力における行の欠落の評価• 手法：提案手法を IBM Global Bussiness Services に組み込んだものを用い，

バグのある13 のABAP サンプルについて欠陥箇所を特定する．• 結果：13プログラム中12 のプログラムで欠陥箇所を特定できた．また，そ

のうち9プログラムのバグは従来の手法では見つからない．

11図は Saha et.al., “Fault Localization for Data-Centric Programs” p165 より

Mitigating the Confounding Effects of Program Dependencies

for Effective Fault Localization論文著者： George K. Baah, Andy Podgurski,

Mary Jean Harrold

担当者：石尾隆（大阪大学）

論文の概要

• 統計的な Fault Localization 手法

– 既存研究から続く考え方：

失敗テストケースで実行された文のほうが，

成功テストケースで実行された文よりも疑わしい

• プログラム文の疑わしさを求める方法が研究のポイント

– 提案手法：成功・失敗のテストケースが「同じ条件で，その文を実行した」と言えるようにテストケースを選択

• 文の実行に影響を与える文のカバレッジを比較

• 著者らの従来手法では動的制御依存を考慮していたが，今回は動的データ依存も加えた 13

アプローチの基本モデル論文 Figure 1 テストケース 5個

テスト対象プログラム

各文のカバレッジ . 実行したら 1.テストの成否 .失敗したら 1.

基本モデル : Equation (1)

文 s がテスト失敗に関与している度合いτ = E[Y1] – E[Y0]

Y1: s を実行した文がテストに失敗するとき 1 ，成功するとき0 となる確率変数．Y0: s を実行しなかった文がテストに失敗するとき 1 ，そうでないとき 0 .

E[Y1] = Y1 の期待値．すなわち， s を実行した文がテストに失敗する確率． 14

Confounding Effect の問題

• １つの条件分岐が複数の文の実行を制御する　　　　　　　　単純なカバレッジでは違いを区別できない

• 成功と失敗をそれぞれ公平にサンプリングしていない　統計的モデルの適用に相応しくない

同一の IF 文（ 3 行目）に制御されるすべての文でτ の値が同じになってしまう

本研究の提案

文 s の評価値 τ を決める「対等な」テストケースの選択法

1. Dynamic PDG から， s への依存辺を持つ文の集合 D を取り出す• 文を頂点とし，動的な依存関係を辺とするPDG　 (SDGではない )

2. 各テストケースを，D のカバレッジを表現するベクトルに変換する• テストケースが， D の各文を実行していたら 1, そうでなければ 0 の値とし

て， |D| 個の要素の数値ベクトルとする．

3. ベクトル間のマハラノビス距離を求め，成功テストケースと失敗テストケースの組を，距離が近いものから，できるだけ多く取り出す．• 「文 s が実行された状況ができるだけ近い」成功テストケースと失敗テスト

ケースの組を選んでいくことになる

• マハラノビス距離で，相関を考慮 16

既存手法との組み合わせ

テストケースの組が取り出せない場合は，著者らの従来手法で推定

– ある文 s を実行したテストケースがすべて成功である場合や，類似度が低い場合にこちらの処理を使う

– Equation (6): 「文 s が実行されたかどうか」と「文 s に動的制御依存を与える文が実行されたかどうか」の２つの値から，テストケースの失敗を表現する線形回帰モデル• データ依存が入っていないことには注意

評価実験

• プログラム文を，文の評価値 τ でソートしたとき，バグ修正の対象となった文が，何番目に来るかで評価

– τ の値に従って上位から順に調べた場合の開発者の労力を評価

– 評価値が同じ文は，すべて同時に調査対象となると考える

• 既存手法 Tarantula, Ochiai との比較実験で改善を示した

– 50%程度のバグには，既存手法よりも良い結果を出す．改善幅は 0.05%～60%

– 20%程度のバグには，既存手法よりも悪い結果を出す18

おわり

f05: debugging

Documents

debugging habits

06 hdl debugging

java debugging tips @oredev

javascript debugging (동영상강의자료)

cloud hardcore debugging

folderenergybull f05 2015

php ile debugging

debugging mod perl

dam080101e02 debugging pocorullneus

kernel debugging(번역).pdf

base datos f05

qr accessibilite-nrh f05

debugging und profiling

debugging in windows env

windows debugging technique #2

for nte series electric...gx9 llxll 14x14 flang stem f03 f05...

virtual chip os vlsi systems lab 정무경. 진행 상황...

debugging server with strace

scalable post-mortem debugging

debugging in the eclipse