session m: debugging

33
Session M: Debugging ICSE2013 勉勉勉 勉勉 勉勉勉 勉勉勉勉 勉勉勉勉 <[email protected]> 2013/7/9 ICSE2013 勉勉勉 SessionM 1 References [M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341 [M2] PorchLight: A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351 [M3] Expositor: Scriptable Time-Travel Debugging with First-Class Traces K. Y. Phang, et al. Proc. ICSE2013, pp.352-361 [M4] Chronicler: Lightweight Recording to Reproduce Field Failures

Upload: darren

Post on 15-Feb-2016

34 views

Category:

Documents


0 download

DESCRIPTION

Session M: Debugging. ICSE2013 勉強会 担当:東工大 情報理工 小林隆志 . References [M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341 [M2] PorchLight : A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Session M: Debugging

Session M: DebuggingICSE2013 勉強会 担当:東工大 情報理工 小林隆志 <[email protected]>

2013/7/9ICSE2013 勉強会 SessionM1

References[M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341[M2] PorchLight: A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351[M3] Expositor: Scriptable Time-Travel Debugging with First-Class Traces K. Y. Phang, et al. Proc. ICSE2013, pp.352-361[M4] Chronicler: Lightweight Recording to Reproduce Field Failures J. Bell et al. Proc. ICSE2013, pp.362-371

Page 2: Session M: Debugging

2

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

分野:バグフィックス,開発活動分析 種別:アンケートの分析 論文概要:

バグフィックスにおける,修正方針の選択がどのようになされているかをアンケート等をベースに議論.修正候補と選択方針のモデル “ Design of Bug Fixes” を提示 4 手法のデータを分析.詳細は TR[17] で公開 ( 今は見えない… ) 修正候補や選択方針の統計情報をデバッグの研究に活用する方

向性を示している

所感: かなり赤裸々に公開している印象.多くは納得の結果だが

意外な事実も含まれている.テクニカルレポートが見たい… .2013/7/9ICSE2013 勉強会 SessionM

M1

Page 3: Session M: Debugging

3

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

The Design of Bug Fixes

2013/7/9ICSE2013 勉強会 SessionM

M1

Reprinted from [M1] “Fig. 1. Characterizing the design of bug fixes ”

RQ1: どの様な観点で

修正候補を検討してRQ2: どの様な要因が

修正候補を決定するか

Page 4: Session M: Debugging

4

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

Design Space : どんな修正候補を検討するか Data Propagation Across Components

レイヤをまたいだバグの場合,ソース側か利用側か Error Surfacing

エラーをユーザに見せるかどうか Behavioral Alternatives

ユーザ操作の変更を伴うかどうか Functionality Removal Refactoring Internal vs External

自分の担当範囲を超えるかどうか Accuracy Hardcoding

2013/7/9ICSE2013 勉強会 SessionM

M1

Page 5: Session M: Debugging

5

Design Space : どんな修正候補を検討するか Data Propagation Across Components

レイヤをまたいだバグの場合,ソース側か利用側か Error Surfacing

エラーをユーザに見せるかどうか Behavioral Alternatives

ユーザ操作の変更を伴うかどうか Functionality Removal Refactoring Internal vs External

自分の担当範囲を超えるかどうか Accuracy Hardcoding

「2つの帽子を持っているが,かぶりなおすことはしない」 バグフィックス中にリファクタリングすべき点にはよく 気がつくが, リファクタリングしないことが多い

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

2013/7/9ICSE2013 勉強会 SessionM

M1

Reprinted from [M1] Table II

Page 6: Session M: Debugging

6

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

修正案を決定する要因 Risk Management by Development Phase Interface Breakage → Usually 36%, Always 53% Consistency → Usually 50%, Always 28% User Behavior Cause Understanding Social Factors

だれと相談するか? → ほとんどが同僚.ボスは極少数

2013/7/9ICSE2013 勉強会 SessionM

M1

Page 7: Session M: Debugging

7

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

Risk Management by Development Phase リリースサイクルでの位置,変更行数,

テスト労力,実装にかかる工数 の考慮度合 ( 表 III-A) 選択した方針より良い実装が見つかった場合

再修正するか ? → しないことが多い [ 重要 ] ( 表 IV)

2013/7/9ICSE2013 勉強会 SessionM

M1

Reprinted from [M1] Table III-A Reprinted from [M1] Table IV

リポジトリにある修正は,ベストな学習データではないかもしれない!

Page 8: Session M: Debugging

8

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

User Behavior : UI の変更をどう判断する? 利用頻度の情報を使うか?

あまり使わないで決定している

2013/7/9ICSE2013 勉強会 SessionM

M1

Reprinted from [M1] Table V

Reprinted from [M1] Table III-D

SQM(MS の製品の利用情報 ) などのデータを使うケースも 3 割程度ある

Microsoft 社の Web サイトより

使う場合,開発者サイドの経験に基づく場合が半数以上

Page 9: Session M: Debugging

9

The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR)

Implications : ( 研究ネタの参考になります ) バグ予測・特定の Additional Factor

リリース直前の bug fix と それ以外は特徴が異なる 要因によっては取得困難→バグ予測・特定の限界

bug fix 中のリファクタリングの支援が必要 ツール支援が重要.精度や使いやすさを改善するべき

利用状況の分析 重要だが現状では活用するには課題が多い→改善が必要

適切なデータソースを発見し, 複雑な SQL を書いて問い合わせ

変更推薦 ad-hoc 対応で“ TODO ” とコメントしたままのコードが残

る どの“ TODO” を早期に見直すべき見極めることが難しい

2013/7/9ICSE2013 勉強会 SessionM

M1

Page 10: Session M: Debugging

Session M: DebuggingICSE2013 勉強会 担当:東工大 情報理工 小林隆志 <[email protected]>

2013/7/9ICSE2013 勉強会 SessionM10

References[M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341[M2] PorchLight: A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351[M3] Expositor: Scriptable Time-Travel Debugging with First-Class Traces K. Y. Phang, et al. Proc. ICSE2013, pp.352-361[M4] Chronicler: Lightweight Recording to Reproduce Field Failures J. Bell et al. Proc. ICSE2013, pp.362-371

Page 11: Session M: Debugging

11

PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine)

分野: Bug Triaging, BTS (Bug Tracking System) 種別:手法・ツール提案 論文概要:

デバッグ用ではなく,バグトリアージ (BT) 用のタグを提供することで, BTS における BT を効率化するツールの提案.

専用言語 BTL でフィルタを容易に定義可能

評価: 10 問の 5 段階のアンケート 実際にトリアージしている 6 人の専門家 ( 開発者, PM)

がツールを利用 好評化 (4.3-5.0) だった (平均値と意見の紹介のみ !!!!)

※「バグトリアージ」 (BTS に ) 報告された問題に対して, * 適切な * 開発者と マイルストーンを設定すること

2013/7/9ICSE2013 勉強会 SessionM

M2

Page 12: Session M: Debugging

12

PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine)

バグトリアージに必要な 5 つの要件 文献調査と開発経験, OSS 開発者の意見を分析A) バグレポートを簡単にソート・フィルターできる

何度も別の開発者に再割り当てされているバグ など 14日以上担当者から反応のないバグ

B) Ad-hoc Grouping できる すぐに判断できないバグをまとめて tentative plan を決定す

C) 過去の割り当て情報・未割当のバグレポート情報に 容易にアクセスできる D) Rich Bug Histories の提供

関連する活動(コードのコミット,コメント)の履歴

E) Single Context トリアージに必要な情報を同じインターフェースで提供

2013/7/9ICSE2013 勉強会 SessionM

M2

Page 13: Session M: Debugging

13

PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine)

スクリーンショット (MIRTH-1968 を選択中 )

2013/7/9ICSE2013 勉強会 SessionM

M2

This figure is reprinted from [M2] “Fig 1. PorchLight user interface. ”

開発者リスト マイルストーンバグリポート リスト

バグリポート詳細活動タイムライン

活動タイムラインの詳細 ( コミット,割り当ての情報 )

クイックフィルタ 検索タグ

名前と割当実績

Page 14: Session M: Debugging

14

PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine)

4 種のタグ種別をサポート典型的なもの: 1) Predefined , 2) Developer,

Milestone BTL で定義するもの : 3) ad-hoc tag, 4) user-

defined tag BTL (Bug Tagging Language)

2013/7/9ICSE2013 勉強会 SessionM

M2

Reprinted from [M2] “Table 1. Example BTL statements. ”

Page 15: Session M: Debugging

15

PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine)

評価 6 人の実務開発者・ PM が 45-60 分の評価 5 段階アンケートを 10 問

アンケート項目 (Q1,2,8,9,10 のみ登場 ) トリアージが必要なバグを容易に認識できた (ave

4.3) 実際のトリアージ作業が容易になった (ave 5.0)

activity time line が有効 タグセットと BTL は有用である (ave 4.5)

BTL の文法を覚えていなくてもサンプルをもとに使えていた既存ツールよりもトリアージが容易 (ave 4.5) 今後 PorchLight を使いたいか? (ave 4.5)

2013/7/9ICSE2013 勉強会 SessionM

M2

Page 16: Session M: Debugging

16

PorchLight: A Tag-Based Approach to Bug Triaging

所感:各機能は Trac などにあり新規性は低い印象

評価されたであろうポイント トリアージ作業に特化したところ 統合 UI の機能デザイン と BTL の汎用性

綿密な実験&分析がなくとも ICSE に通る ( こともあ

る )! Intro(1.5p) relatedwork(0.7p) conclusion&ref(1p) BT に対する要件 (1.5p), ツールの紹介 (4p) ← ほぼ提案・紹介

評価方法 (0.5p) 結果 (0.5p) 議論 (0.4p) Threats (0.4p)2013/7/9ICSE2013 勉強会 SessionM

M2

Page 17: Session M: Debugging

Session M: DebuggingICSE2013 勉強会 担当:東工大 情報理工 小林隆志 <[email protected]>

2013/7/9ICSE2013 勉強会 SessionM17

References[M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341[M2] PorchLight: A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351[M3] Expositor: Scriptable Time-Travel Debugging with First-Class Traces K. Y. Phang, et al. Proc. ICSE2013, pp.352-361[M4] Chronicler: Lightweight Recording to Reproduce Field Failures J. Bell et al. Proc. ICSE2013, pp.362-371

Page 18: Session M: Debugging

18

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

分野: Scriptable デバッガ,動的解析 種別:手法・ツールの提案 論文概要:

call-back スタイルでなく , functional reactive programming (FRP) スタイルの Scriptable な time-travel debugger を提案. Running example を通してツールの効果を示している.

※ Scriptable Debuggergdb の Python インターフェースを利用すると,ステップ実行や breakpoint の設定などがスクリプトで記述できる.

Time-Travel debugger 実行を記録して再生することでバグを再現して原因を特定する. Omniscient debuggers と replay debuggers の 2 つに分類している

2013/7/9ICSE2013 勉強会 SessionM

M3

Page 19: Session M: Debugging

19

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

提案手法の特徴 FRP-style scriptable time-travel debugging

プログラム=イベント生成器 イベント=関数呼び出し,メモリ参照 プログラムの実行=イベントシーケンスとなる

Callback-style の UndoDB[5] と gdb の pythonインターフェースをベースに実現

laziness を考慮して, UndoDB の呼出しを削減→高速化

保持する内部データを表現する,新しいデータ構造edit hash array mapped trie (EditHAMT) を提案

2013/7/9ICSE2013 勉強会 SessionM

M3

Page 20: Session M: Debugging

20

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

Expositor の概要 execution

全ての brakepoint, 関数 entiry/exit などが取得できる内部的に UndoDB に問い合わせを行う

2013/7/9ICSE2013 勉強会 SessionM

M3

Reprinted from [M3] “Fig. 1. EXPOSITOR’s Python-based scripting API (partial).”

Page 21: Session M: Debugging

21

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

Expositor の概要 trace クラス

execution から取得した各種イベントに対して,演算を行うクラス

2013/7/9ICSE2013 勉強会 SessionM

M3

Reprinted from [M3] “Fig. 1. EXPOSITOR’s Python-based scripting API (partial).” Reprinted from [M3] “Fig. 2. Illustration of complex trace operations.”

Page 22: Session M: Debugging

22

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

効率化のための工夫: Lazy Trace 概要:必要でないトレースを取得・展開しないよう

に木構造で表現.部分木は必要になったら段階的に作成

2013/7/9ICSE2013 勉強会 SessionM

M3

時間 0 ~無限大のトレースこの時点では エントリポイントのみ

All figures are reprinted from [M3]

1) foo.get_before(100) を実行2) UndoDB に問い合わせて, t=50 で呼び出しがあったと回答があった3) この後から解析をしようとすると… .

時間 50 のイベントだけ記憶( そのほかのイベントはまだ登場しない )

Page 23: Session M: Debugging

23

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

Expositor を利用した Debug の例「スクロールすると大量の一次オブジェクト (70MB)

が発生して, 2回目のスクロールの 20秒後に解放される」という Firefox のメモリ遅延解放のバグ

までの実行が 126[s] で終了 , 最大メモリ 383[MB] UndoDB ベースの既存システムだと 351[MB]

2013/7/9ICSE2013 勉強会 SessionM

M3

Reprinted from [M3] “Fig. 5. Timeline of items in traces used to debug Firefox.”

連続したメモリ確保

watchpoint を設定して疑わしい箇所を特定 (Write-lock が原因 )

GC はちゃんと動いてる

Page 24: Session M: Debugging

24

Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland)

所感 UndoDB の利用効率化のために, trace データの管理方法として木構造を利用し遅延評価する点が面白い

執筆スタイルが特殊 コードと起動方法が逐一掲載してあり,どのように

デバッグを行うかわかりやすい (?)

2013/7/9ICSE2013 勉強会 SessionM

M3

Page 25: Session M: Debugging

Session M: DebuggingICSE2013 勉強会 担当:東工大 情報理工 小林隆志 <[email protected]>

2013/7/9ICSE2013 勉強会 SessionM25

References[M1] The Design of Bug Fixes E. Murphy-Hill, et al. Proc. ICSE2013, pp.332-341[M2] PorchLight: A Tag-Based Approach to Bug Triaging G. Bortis, et al. Proc. ICSE2013, pp.342-351[M3] Expositor: Scriptable Time-Travel Debugging with First-Class Traces K. Y. Phang, et al. Proc. ICSE2013, pp.352-361[M4] Chronicler: Lightweight Recording to Reproduce Field Failures J. Bell et al. Proc. ICSE2013, pp.362-371

Page 26: Session M: Debugging

26

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

分野:リモートデバッグ,バグ再現, 種別:手法・ツールの提案・実験による評価 論文概要:

Record&Replay型のリモートデバッグで必要な情報を低オーバヘッドで取得する手法・ツールを提案.複数の実験を実施,最悪でも 86% ,平均的には 10% 以下のオーバヘッドであり, RecrashJ [3/ECOOP’08] に比べ高性能.

貢献:低オーバーヘッドのログ取得手法を提案

既存ツールの最悪ケースは 10000% 実際に利用できるツール Chronicler を公開

2013/7/9ICSE2013 勉強会 SessionM

M4

Page 27: Session M: Debugging

27

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

リモートデバッグ本番環境 (field) で発生した不具合はその場でデバッ

グできない.必要な情報を取得し,開発環境 (lab) で再現させる必要がある.

Record & replay 型: 本番環境で取得したログを基に,開発環境で同じ状態 (bug

reproduce) になる入力 ( テストケース ) を作成する.他に, De-JaVu[13], jRapture[41] などがある.

2013/7/9ICSE2013 勉強会 SessionM

M4

Reprinted from [M4] “Fig. 1: High Level Overview of CHRONICLER ”

Page 28: Session M: Debugging

28

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

手法の概要 : Reprinted from [M4] “Fig. 3: CHRONICLERJ Implementation Overview”

p

ポイント non-deterministic method (ndm = UI/File/Network との I/O

を伴うメソッド,乱数生成など ) を検出. ( 詳細は IV-A) ndm の全呼び出しに計装し,返り値を記録 (IV-B, IV-C) Replay バージョンで,記録した返り値を利用 (IV-D)

2013/7/9ICSE2013 勉強会 SessionM

M4

IV-A

IV-B IV-C

IV-D

Page 29: Session M: Debugging

29

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

評価オーバヘッドの計測 (1)

DeCapo Benchmark website [9] のワークロードを使用 eclipse, tomcat, pmd などの利用ログ

オーバヘッドの計測 (2) ReCrashJ の論文のデータで, ReCrashJ と比較. SVNKit, Eclipse 2.1 Java Compiler を実行

オーバヘッドの計測 (3) SciMark2.0[38] を使って,計算タスクでの影響や I/O の量が増大した場合の影響を調査.

高速フーリエ変換,モンテカルロ法などを計算

2013/7/9ICSE2013 勉強会 SessionM

M4

Page 30: Session M: Debugging

30

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

評価オーバヘッドの計測 (1)

DeCapo Benchmark website [9] のワークロードを使用

2013/7/9ICSE2013 勉強会 SessionM

M4

Reprinted from [M4]

黒 ( 通常実行 ) と灰色 ( 提案手法 ) はほぼ一致 = 低オーバヘッド網掛けが 比較手法

Page 31: Session M: Debugging

31

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

評価オーバヘッドの計測 (2)

ReCrashJ の論文のデータで, ReCrashJ と比較.オーバヘッドの計測 (3-1)

SciMark2.0[38] を使って,計算タスクでの影響を確認

2013/7/9ICSE2013 勉強会 SessionM

M4

Reprinted from [M4] Reprinted from [M4]

Overhead < 1%

Page 32: Session M: Debugging

32

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

評価オーバヘッドの計測 (3-2)

I/O を記録するため, I/O のファイルサイズに影響があることを確認する実験 (java.io.BufferedReader#readLine()を 100回実行 )

2013/7/9ICSE2013 勉強会 SessionM

M4

Reprinted from [M4]

← 86% = WORST

Page 33: Session M: Debugging

33

Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.)

所感完成度の高いツール実装

Reflection までサポート.範囲を限定して達成したパフォーマンスではない.

解析ツールの評価をするうえで,広範囲な対象実験には必須だが難しい.

関連研究の replication & 比較 をしっかり実施

再現性に関しては議論されていない

2013/7/9ICSE2013 勉強会 SessionM

M4