1 / 33

Session M: Debugging

Session M: Debugging. ICSE2013 勉強会 担当：東工大 情報理工 小林隆志 <tkobaya@acm.org>. 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

darren
Download Presentation

Session M: Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SessionM:Debugging ICSE2013 勉強会 担当：東工大 情報理工 小林隆志 <tkobaya@acm.org> 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 TriagingG. 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 ICSE2013勉強会 SessionM

  2. M1 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]で公開 (今は見えない…) • 修正候補や選択方針の統計情報をデバッグの研究に活用する方向性を示している • 所感： • かなり赤裸々に公開している印象．多くは納得の結果だが意外な事実も含まれている．テクニカルレポートが見たい…. ICSE2013勉強会 SessionM

  3. M1 The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR) • The Design of Bug Fixes RQ1:どの様な観点で修正候補を検討して RQ2: どの様な要因が修正候補を決定するか Reprinted from [M1] “Fig. 1. Characterizing the design of bug fixes ” ICSE2013勉強会 SessionM

  4. M1 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 vsExternal • 自分の担当範囲を超えるかどうか • Accuracy • Hardcoding ICSE2013勉強会 SessionM

  5. M1 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 vsExternal • 自分の担当範囲を超えるかどうか • Accuracy • Hardcoding • 「２つの帽子を持っているが，かぶりなおすことはしない」 • バグフィックス中にリファクタリングすべき点にはよく 気がつくが， リファクタリングしないことが多い Reprinted from [M1]Table II ICSE2013勉強会 SessionM

  6. M1 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%, Always53% • Consistency → Usually 50%, Always 28% • User Behavior • Cause Understanding • Social Factors • だれと相談するか？ → ほとんどが同僚．ボスは極少数 ICSE2013勉強会 SessionM

  7. M1 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) リポジトリにある修正は，ベストな学習データではないかもしれない！ Reprinted from [M1]Table III-A Reprinted from [M1]Table IV ICSE2013勉強会 SessionM

  8. M1 The Design of Bug FixesE. Murphy-Hill (North Carolina State U), T. Zimmermann, C. Bird, N. Nagappan (MSR) • User Behavior :UIの変更をどう判断する？ • 利用頻度の情報を使うか？ • あまり使わないで決定している Reprinted from [M1]Table III-D 使う場合，開発者サイドの経験に基づく場合が半数以上 Microsoft社のWebサイトより • SQM(MSの製品の利用情報) などのデータを使うケースも3割程度ある Reprinted from [M1]Table V ICSE2013勉強会 SessionM

  9. M1 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” を早期に見直すべき見極めることが難しい ICSE2013勉強会 SessionM

  10. SessionM:Debugging ICSE2013 勉強会 担当：東工大 情報理工 小林隆志 <tkobaya@acm.org> 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 TriagingG. 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 ICSE2013勉強会 SessionM

  11. M2 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に)報告された問題に対して，*適切な*開発者と マイルストーンを設定すること ICSE2013勉強会 SessionM

  12. M2 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 • トリアージに必要な情報を同じインターフェースで提供 ICSE2013勉強会 SessionM

  13. M2 PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine) • スクリーンショット (MIRTH-1968を選択中) 検索 クイックフィルタ タグ 開発者リスト マイルストーン バグリポート リスト バグリポート詳細 活動タイムライン 活動タイムラインの詳細 (コミット，割り当ての情報) 名前と割当実績 Thisfigure is reprinted from [M2] “Fig 1. PorchLight user interface. ” ICSE2013勉強会 SessionM

  14. M2 PorchLight: A Tag-Based Approach to Bug TriagingG. Bortis and A. Hoek (UC Irvine) • 4種のタグ種別をサポート • 典型的なもの： 1) Predefined, 2) Developer, Milestone • BTLで定義するもの:3) ad-hoctag, 4) user-defined tag • BTL(Bug Tagging Language) Reprinted from [M2] “Table 1. Example BTL statements. ” ICSE2013勉強会 SessionM

  15. M2 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) ICSE2013勉強会 SessionM

  16. M2 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) ICSE2013勉強会 SessionM

  17. SessionM:Debugging ICSE2013 勉強会 担当：東工大 情報理工 小林隆志 <tkobaya@acm.org> 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 TriagingG. 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 ICSE2013勉強会 SessionM

  18. M3 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を提案．Runningexampleを通してツールの効果を示している． ※ ScriptableDebugger gdbのPython インターフェースを利用すると，ステップ実行や breakpointの設定などがスクリプトで記述できる． Time-Travel debugger 実行を記録して再生することでバグを再現して原因を特定する． Omniscient debuggers と replay debuggers の2つに分類している ICSE2013勉強会 SessionM

  19. M3 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)を提案 ICSE2013勉強会 SessionM

  20. M3 Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland) • Expositorの概要 • execution • 全てのbrakepoint, 関数entiry/exit などが取得できる • 内部的にUndoDBに問い合わせを行う Reprinted from [M3] “Fig. 1. EXPOSITOR’s Python-based scripting API (partial).” ICSE2013勉強会 SessionM

  21. M3 Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland) • Expositorの概要 • trace クラス • executionから取得した各種イベントに対して，演算を行うクラス Reprinted from [M3] “Fig. 1. EXPOSITOR’s Python-based scripting API (partial).” Reprinted from [M3] “Fig. 2. Illustration of complex trace operations.” ICSE2013勉強会 SessionM

  22. M3 Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland) • 効率化のための工夫：LazyTrace • 概要：必要でないトレースを取得・展開しないように木構造で表現．部分木は必要になったら段階的に作成 時間0～無限大のトレース この時点では エントリポイントのみ foo.get_before(100) を実行 UndoDBに問い合わせて，t=50で呼び出しがあったと回答があった この後から解析をしようとすると…. 時間50のイベントだけ記憶 (そのほかのイベントはまだ登場しない) Allfigures are reprinted from [M3] ICSE2013勉強会 SessionM

  23. M3 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] 連続したメモリ確保 GCはちゃんと動いてる Reprinted from [M3] “Fig. 5. Timeline of items in traces used to debug Firefox.” watchpointを設定して疑わしい箇所を特定 (Write-lockが原因) ICSE2013勉強会 SessionM

  24. M3 Expositor: Scriptable Time-Travel Debugging with First-Class TracesK. Y. Phang, J. S. Foster, M. Hicks (U. Maryland) • 所感 • UndoDBの利用効率化のために，traceデータの管理方法として木構造を利用し遅延評価する点が面白い • 執筆スタイルが特殊 • コードと起動方法が逐一掲載してあり，どのようにデバッグを行うかわかりやすい(?) ICSE2013勉強会 SessionM

  25. SessionM:Debugging ICSE2013 勉強会 担当：東工大 情報理工 小林隆志 <tkobaya@acm.org> 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 TriagingG. 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 ICSE2013勉強会 SessionM

  26. M4 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を公開 ICSE2013勉強会 SessionM

  27. M4 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] などがある． Reprinted from [M4] “Fig. 1: High Level Overview of CHRONICLER ” ICSE2013勉強会 SessionM

  28. M4 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-deterministicmethod (ndm = UI/File/Network との I/O を伴うメソッド，乱数生成など ) を検出．(詳細は IV-A) • ndmの全呼び出しに計装し，返り値を記録 (IV-B, IV-C) • Replayバージョンで，記録した返り値を利用 (IV-D) IV-A IV-D IV-B IV-C ICSE2013勉強会 SessionM

  29. M4 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の量が増大した場合の影響を調査． • 高速フーリエ変換，モンテカルロ法などを計算 ICSE2013勉強会 SessionM

  30. M4 Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.) • 評価 • オーバヘッドの計測(1) • DeCapo Benchmark website [9] のワークロードを使用 黒(通常実行)と灰色(提案手法)は ほぼ一致 ＝ 低オーバヘッド 網掛けが 比較手法 Reprinted from [M4] ICSE2013勉強会 SessionM

  31. M4 Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.) • 評価 • オーバヘッドの計測(2) • ReCrashJの論文のデータで，ReCrashJと比較． • オーバヘッドの計測(3-1) • SciMark2.0[38] を使って，計算タスクでの影響を確認 Overhead <1% Reprinted from [M4] Reprinted from [M4] ICSE2013勉強会 SessionM

  32. M4 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回実行) ← 86% ＝WORST Reprinted from [M4] ICSE2013勉強会 SessionM

  33. M4 Chronicler: Lightweight Recording to Reproduce Field FailuresJ. Bell, N. Sarda and G. Kaiser (Columbia U.) • 所感 • 完成度の高いツール実装 • Reflectionまでサポート．範囲を限定して達成したパフォーマンスではない． • 解析ツールの評価をするうえで，広範囲な対象実験には必須だが難しい． • 関連研究のreplication & 比較 をしっかり実施 • 再現性に関しては議論されていない ICSE2013勉強会 SessionM

More Related