Precomputing Possible Configuration Error Diagnoses

1. Precomputing Possible Configuration ErrorDiagnoses 東京工業大学　権藤研究室　石井惇志

2. 研究の背景・目的 • ソフトウェアの導入において、Configurationのミスで正しく動作しない事はよくある • エラーメッセージが親切でない事も多く、エラー診断が難しい • オープンソースで顕著 • 本研究では、エラーメッセージから、原因となりうるオプションを提示したい • Webサービスの形で提供できると良い • クエリとしてエラーメッセージ→エラー診断を返す エラーメッセージ 提案手法のWebサービス 診断結果 “NullPointerException at line 134 of NetUtils.java” ～の設定が怪しい！

3. 提案手法の概要 • 対象言語はJava • 解析アルゴリズムのOverview • Configurationにラベルを付ける • データフロー解析をして、先程つけたラベルとの関連付けを行う • ソースコード中のある位置と、そこに関連するオプションの対応表を生成する

4. 解析アルゴリズムの詳細 • Static Analysis • 本研究のベースとなるアルゴリズム（前頁） • Failure-context-sensitive(FCS) analysis • エラー時のスタックトレースに含まれる部分について再解析し、関係のないパスを枝刈りする • Dynamic Approaches • 実行時のデータも解析に含めるオプション • どのオプション項目を読み込んだか、それがどこにあるか • オプションを読み込んだ時の処理フローを記録する

5. 評価方法 • Hadoopと JChordについて、Fault Injectionを行なって、エラー原因のオプションを提示できるか実験 • Failure-context-sensitive analysis やDynamic Approachが効いているかについても実験 • 下表がFault Injectionの実験結果 • False Positiveの平均が1~3.5と低く抑えられている

6. 評価結果 • アルゴリズムごとの比較 • Dynamic ApproachとFCSが効いているのが分かる

7. 考察 • 提案手法の課題 • 提案手法の導入には、一定のプログラム作法に従う必要がある • 「すべての例外をcatchし、『一般的な』エラーメッセージを返す」ようなプログラムでは導入しても成果が出づらい • 「エラーメッセージは特定のプログラムコードを指す」という暗黙の前提があるため • ConfigrationをKey-Valueの集合と仮定しているので、その範囲を超える場合には対応できない（任意のデータ型など） • 「何故そのオプションがおかしいのか」は提示しない • 正確なエラー原因の提示機能はFuture work

8. Optiamal Divide and Query 権藤研　岡田隆秀

9. 概要 • Algorithmic Debuggingに関する論文 • 従来のアルゴリズム(D&Q)には問題があった • 主に最適性に問題 • この問題を解決する論文 • optimal D&Q • 結論 • 従来手法や他のベンチマークよりも2~36%速くなった

10. Algorithmic Debugging • プログラマーに質問を投げかけBugを発見する手法 • 例：挿入ソート(本来:昇順、バグコード:降順) この論文は この質問の順番を最適化して 質問数を減らそうというもの ET (execution tree)

11. 従来の手法 • Divide and Query • ざっくり言うと、 • 現在の重みの1/2に近いノードを次のノードにする • a • n • z • 回答がYesのノードのみだと最適でない • Noのノードがあっても個々の重みが異なると最適でない • Noのノードがあると完全性に問題

12. 新たな手法 • Optimal Divide and Query • ざっくりな説明 • となるようなノードを優先的に選ぶ Up(n1)=8 Down(n1)=11 Up(n2)=12 Down(n2)=7

13. 論文内での検討 • 前述の手法は個々のノードの重さが全て1であった • このため、重さを　　　　　　の範囲で検討 • 正当性には問題なし • 完全性に問題があった • 完全性を保証するためには　　とする必要があった

14. 結論 • 最大で約36%の質問比率の減少 • ET内で質問を行ったノードの割合 • バグのあるノードを仮定して、何度か試行しその平均を算出

15. Localizing SQL Faults in Database Applications 権藤研究室　内田公太

16. 背景・目的 • 多くのアプリがデータベースを利用する。 • しかし、既存のフォールト位置特定技術は、一つのプログラミング言語しか解釈してくれない。 • Java向けの技術ではSQLまではチェックしない。 • データベースを考慮に入れたフォールト位置特定技術を開発したい！

17. 従来手法の問題 • 発行されるSQL以外に問題がない場合、エラー箇所を特定できない。 whereClause に間違いを組み 込んである。 printProductsSold(String userType, String userID) { 1 String Attributes = conf.getAttributes(userType, userID); 2 String whereClause = conf.getWhere(userType, userID); 3 String SQL = "SELECT "+ Attributes + " FROM Sale WHERE" + whereClause; 4 PreparedStatementps = new PreparedStatement(); 5 ResultSetrs = ps.executeQuery(SQL); 6 printResultSet(rs); } どのテストケース（A-G）も 全行を実行しているため、 「どの行も等しく怪しい」 としか分からない。

18. 提案手法 • 実際に発行されたSQLを補足し、利用することで、エラー箇所を特定する。 whereClause に間違いを組み 込んである。 printProductsSold(String userType, String userID) { 1 String Attributes = conf.getAttributes(userType, userID); 2 String whereClause = conf.getWhere(userType, userID); 3 String SQL = "SELECT "+ Attributes + " FROM Sale WHERE" + whereClause; 4 PreparedStatementps = new PreparedStatement(); 5 ResultSetrs = ps.executeQuery(SQL); 5a <5, SELECT Product, Price FROM Sale WHERE MerchantID >= ?> 5b <5, SELECT Product, Price FROM Sale WHERE CustomerID = ?> 6 printResultSet(rs); } 2/3失敗 してる。 アヤシイ！ 発行されたSQLを考慮すると、 テストケース毎のカバレッジに 差が出る！

19. 評価結果 • 実際のJavaで作られた3製品に対して適用してみた。 • iTrust, JWhoisServer, MessageSwitch • 各製品に対し、人為的にエラーを埋め込む。 • 不良挿入演算子（mutation operator）を使う。 • 「怪しさランキング」の精度により評価。 • 従来手法と提案手法が出力する、怪しさのランキング表の上位1%に、実際のエラー箇所がどのくらい含まれるか 大幅改善！

20. 評価結果の考察 • 製品により、従来手法に対する改善度合いが違った。 • 主に、SQLの実行方法の違いに起因する。 • SQL文字列と発行命令が1対1の場合ps = conn.prepareStatement("UPDATE GlobalVariables SET Value=? WHERE Value='Timeout'");ps.setInt(1, mins);intnumUpdated = ps.executeUpdate(); • ステートメントに基づく従来手法でも、どのSQLが怪しいか分かる。 • 発行命令が数個の関数にまとめられている場合private final synchronizedResultSetexecPST(PreparedStatementpst) throws SQLException {ResultSet res = pst.executeQuery(); return res; } • SQL文字列はすべてその関数に渡され、どのテストケースでもその関数が実行される。そのため、従来手法だとどのSQLが怪しいかは分からない。 • 提案手法なら、ステートメントと実行されたSQLの対で考えるため、同じ文で実行された複数のSQLを区別して怪しさを計算できる！

21. もう一つの利点 • SQL文字列が複雑に構築される場合にも有用 • SQL文字列が、単純なStringコンスタントではなく、複数のメソッドを使って動的に構築されると、実際に実行されたSQLが分かりづらい。 • 提案手法では、プログラム中の怪しい箇所と、そこで実行されたSQLを紐付けして表示してくれるから、分かりやすい！ dbpool.java:631select descr, netname as network, bytelength,inetnumstart, inetnumend, source from inetnum where inetnumstart <= ? and inetnumend >= ? and bytelength = ? order by inetnumstartasc, inetnumendascSuspiciousness: 0.9128709291752769

22. 引用情報 • スライド中のソースコード片、表は • Rabkin, Ariel, Katz Randy, Precomputing Possible Configuration Error Diagnoses, In the Proceedings of the 26th IEEE/ACM International Conference on Automated Software Engineering, Lawrence, Kansas, November 2011. • Optimal Divide and Query, David Insa and Josep Silva, L. Antunes and H.S. Pinto (Eds.): EPIA 2011, LNAI 7026, pp. 224–238, 2011. c Springer-Verlag Berlin Heidelberg 2011 • Sarah R. Clark, Jake Cobb, Gregory M. Kapfhammer, James A. Jones, and Mary Jean Harrold. Localizing SQL Faults in Database Applications. In the Proceedings of the 26th IEEE/ACM International Conference on Automated Software Engineering, Lawrence, Kansas, November 2011. • に載っているものを引用、または一部抜粋して使っています。