Precomputing Possible Configuration Error

Diagnoses

東京工業大学　権藤研究室　石井惇志

ソフトウェアの導入において、 Configuration のミスで正しく動作しない事はよくある◦ エラーメッセージが親切でない事も多く、エラー診断が難しい◦ オープンソースで顕著

本研究では、エラーメッセージから、原因となりうるオプションを提示したい Web サービスの形で提供できると良い

◦ クエリとしてエラーメッセージ→エラー診断を返す

研究の背景・目的

エラーメッセージ 診断結果

～の設定が怪しい！“NullPointerException at line 134 of NetUtils.java”

提案手法のWebサービス

対象言語は Java 解析アルゴリズムの Overview

1. Configuration にラベルを付ける2. データフロー解析をして、先程つけたラベルとの関連付けを行う3. ソースコード中のある位置と、そこに関連するオプションの対応表を生成する

提案手法の概要

Program Point Option1 NetUtils.java 60 fs.default.name2 NetUtils.java 134 fs.default.name… … …

Static Analysis◦ 本研究のベースとなるアルゴリズム（前頁）

Failure-context-sensitive(FCS) analysis

◦ エラー時のスタックトレースに含まれる部分について再解析し、関係のないパスを枝刈りする Dynamic Approaches

◦ 実行時のデータも解析に含めるオプション どのオプション項目を読み込んだか、それがどこにあるか オプションを読み込んだ時の処理フローを記録する

解析アルゴリズムの詳細

Hadoop と JChord について、 Fault Injectionを行なって、エラー原因のオプションを提示できるか実験◦ Failure-context-sensitive analysis や

Dynamic Approach が効いているかについても実験 下表が Fault Injection の実験結果

◦ False Positive の平均が 1~3.5 と低く抑えられている

評価方法

Target Errors Injected

Avg. False Positives

False Neg.

Success rate

Hadoop HDFS

5 1.0 1 80%

Hadoop MapReduce

6 3.5 1 83%

JChord 7 2.1 1 85%

評価結果 アルゴリズムごとの比較

◦ Dynamic Approach と FCS が効いているのが分かる

提案手法の課題◦ 提案手法の導入には、一定のプログラム作法に従う必要がある

「すべての例外を catch し、『一般的な』エラーメッセージを返す」ようなプログラムでは導入しても成果が出づらい 「エラーメッセージは特定のプログラムコードを指す」という暗黙の前提があるため

◦ Configration を Key-Value の集合と仮定しているので、その範囲を超える場合には対応できない（任意のデータ型など）◦ 「何故そのオプションがおかしいのか」は提示しない

正確なエラー原因の提示機能は Future work

考察

Optiamal Divide and Query

権藤研　岡田隆秀

Algorithmic Debugging に関する論文 従来のアルゴリズム (D&Q) には問題があった

◦ 主に最適性に問題◦ この問題を解決する論文

optimal D&Q 結論

◦ 従来手法や他のベンチマークよりも 2~36% 速くなった

概要

プログラマーに質問を投げかけ Bug を発見する手法 例：挿入ソート ( 本来 : 昇順、バグコード : 降順 )

Algorithmic Debugging

ET(execution tree) この論文はこの質問の順番を最適化して質問数を減らそうというもの

Divide and Query◦ ざっくり言うと、

現在の重みの 1/2 に近いノードを次のノードにする a n z

従来の手法

回答が Yes のノードのみだと最適でない No のノードがあっても個々の重みが異なると最適でない No のノードがあると完全性に問題

Optimal Divide and Query◦ ざっくりな説明

◦ となるようなノードを優先的に選ぶ

新たな手法

n1 n2 def Up(n1) Down(n1) Up(n2) Down(n2)

Up(n1)=8Down(n1)=11

Up(n1) Down(n1) 3

Up(n2)=12Down(n2)=7

Up(n2) Down(n2) 5

前述の手法は個々のノードの重さが全て 1 であった このため、重さを　　　　　　の範囲で検討

◦ 正当性には問題なし◦完全性に問題があった

完全性を保証するためには　　とする必要があった

論文内での検討

R {0}

R

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

結論

Localizing SQL Faults in Database Applications

権藤研究室　内田公太

多くのアプリがデータベースを利用する。 しかし、既存のフォールト位置特定技術は、一つのプログラミング言語しか解釈してくれない。

◦ Java向けの技術では SQL まではチェックしない。 データベースを考慮に入れたフォールト位置特定技術を開発したい！

背景・目的

発行される SQL以外に問題がない場合、エラー箇所を特定できない。

従来手法の問題 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 PreparedStatement ps = new PreparedStatement();5 ResultSet rs = ps.executeQuery(SQL);6 printResultSet(rs); }

A B C D E F G 怪しさ

1 ● ● ● ● ● ● ● 0.532 ● ● ● ● ● ● ● 0.533 ● ● ● ● ● ● ● 0.534 ● ● ● ● ● ● ● 0.535 ● ● ● ● ● ● ● 0.536 ● ● ● ● ● ● ● 0.53

F F P P P P P

どのテストケース（ A-G ）も全行を実行しているため、「どの行も等しく怪しい」としか分からない。

whereClauseに間違いを組み込んである。

実際に発行された SQL を補足し、利用することで、エラー箇所を特定する。

提案手法 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 PreparedStatement ps = new PreparedStatement();5 ResultSet rs = ps.executeQuery(SQL);5a <5, SELECT Product, Price FROM Sale WHERE MerchantID >= ?>5b <5, SELECT Product, Price FROM Sale WHERE CustomerID = ?>6 printResultSet(rs); }

A B C D E F G 怪しさ

4 ● ● ● ● ● ● ● 0.535ab

●●

●●

●●

●

●

●

●

●

●

●

●

0.530.820.00

6 ● ● ● ● ● ● ● 0.53F F P P P P P

発行された SQL を考慮すると、テストケース毎のカバレッジに差が出る！

whereClauseに間違いを組み込んである。

2/3失敗してる。アヤシイ！

実際の Java で作られた 3製品に対して適用してみた。◦ iTrust, JWhoisServer, MessageSwitch

各製品に対し、人為的にエラーを埋め込む。◦不良挿入演算子（ mutation operator ）を使う。

「怪しさランキング」の精度により評価。◦ 従来手法と提案手法が出力する、怪しさのランキング表の上位 1% に、実際のエラー箇所がどのくらい含まれるか

評価結果

対象 誤りの種類 Stmt-base DB-awareiTrust SQL 94.1% 94.1%

Code 97.6% 97.6%JWhoisServer SQL 0.0% 94.6%

Code 17.4% 13.0%MessageSwitch

SQL 50.0% 66.7%Code 26.3% 26.3%

大幅改善！

製品により、従来手法に対する改善度合いが違った。◦ 主に、 SQL の実行方法の違いに起因する。

SQL 文字列と発行命令が 1 対 1 の場合 ps = conn.prepareStatement( "UPDATE GlobalVariables SET Value=? WHERE Value='Timeout'"); ps.setInt(1, mins); int numUpdated = ps.executeUpdate();

◦ ステートメントに基づく従来手法でも、どの SQL が怪しいか分かる。 発行命令が数個の関数にまとめられている場合 private final synchronized

ResultSet execPST(PreparedStatement pst) throws SQLException { ResultSet res = pst.executeQuery(); return res; }

◦ SQL 文字列はすべてその関数に渡され、どのテストケースでもその関数が実行される。そのため、従来手法だとどの SQL が怪しいかは分からない。◦ 提案手法なら、ステートメントと実行された SQL の対で考えるため、同じ文で実行された複数の SQL を区別して怪しさを計算できる！

評価結果の考察

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 inetnumstart asc, inetnumend ascSuspiciousness: 0.9128709291752769

スライド中のソースコード片、表は 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.

に載っているものを引用、または一部抜粋して使っています。

引用情報