. This eight-character test case is of course more we can make most of it? understandable for debugging. ddmin has proved to be useful Failing test cases should be able to guide the debugging in simplifying test cases for programs which can take variable process. In debugging, a small, simple failing test case is more size inputs such as browsers, compilers , lexers and etc. The desirable than a large, complicated test case that represents complexity of ddmin algorithm is quadratic of size of cf . the same failure. Suppose a bug in a browser which causes the browser to crash , developers hardly can inspect a large 2.2 Isolating the failure-inducing parts of test HTML file with thousands of lines that triggers the failure, cases developers in a reasonable amount of time. Therefore, there Test case simplification reduces the size of a test case, but is a desire to simplify the input by minimizing the size of the the simplified failing test case may still include elements which input in such cases. Moreover, a successful test case which is are not necessary for the failure. For example, a minimized very similar to a failing one helps developers to contrast two test case for C compiler may need to preserve some punctua- test cases and may help to further isolating parts of test case tion symbols, like semicolons and parenthesis, to keep the test that lead to the failure. case a valid C program, while those symbols are not related Delta debugging framework facilitates comprehension of a to the failure. One way to tackle this problem is to contrast failure of a program by simplification of test cases (Section the failing test case with a very similar passing test case. With 2.1) and the isolation of failure-inducing parts of test cases that, we can isolate the parts in the failing test case that are (Section 2.2) [43]. It assumes that test cases are composed of not in the passing one, as the failure-inducing portion of the disjoint set of components that can be added to or removed test case. from a test case. These components can be used to contrast Delta debugging framework proposes an algorithm called test cases which in the form of deltas (δs). dd2, that given a pair of passing test case and failing test case (cp, cf ), it attempts to produce a new pair of passing test case 0 0 2.1 Simplification of test cases and failing test case (cp , cp ) with minimal differences. Minimization of a failing test case requires finding the min- Suppose a set of disjoint differences between cp and cf be imum subset of the componenets of the test case that retain ∆ = {δ1, δ2, ..., δk}. That is, if ∆ is applied to cp , it results in the failure. This problem is NP-hard, in general. The simpli- cf . Let “∪” to denote application of a change in a passing test fication algorithm in delta debugging, ddmin, takes a failing case, and “−” to denote removal of a change in the failing test test case and produces a 1-minimal failing test case. A failing case, e.g. test case is 1-minimal if removal any of its constituent com- ponents masks the failure, i.e. causes it to disappear. In this • cp= cf ∪δ1 ∪ ...δk, or case, we can say that all present features in the 1-minimal test • cf = cp−(δ1 ∪ ...δk). case are relevant to the failure. Algorithm 1 depicts the details of ddmin. Assume cf in- We want to find a subset of changes to the (cp,cf ) in or- 0 duces a failure in a program P . To simplify cf , ddmin recur- der to reach a pair (cp’, cf ’) with minimal distance that cp 0 sively splits cf into n subset c1...cn of components. ddmin first passes and cf fails. In general, it requires trying all subsets 0 0 checks if there is ci, 1 ≥ i ≥ n which retains the failure, in of changes to find minimum differences between cp and cf , such cases, it returns the result of simplification of ci. Other- which has exponential time complexity. To be practical, dd2 wise, it checks whether the elimination of each of this subsets produces a pair of a passing test case and a failing test cases 0 0 0 can retain failure, i.e. cf −ci. If so, it simplifies cf −ci. If none with 1-minimal distance. That is, for any δi ∈ cf −cp , cp ∪δi 0 of the previous cases happened, it increases the granularity of would not be a passing test case, and similarly cf −δi is not a partitioning. Initially, this is invoked by ddmin(P, cf , 2). failing test case. In other words, the difference between two Figure 1 (taken from [43]) shows a portion of an HTML file test cases cannot be reduced further. that causes the printing feature of an early version of Mozilla Algorithm 2 outlines the dd2 algorithm. In this algorithm, n Firefox to crash. The original file contains 896 lines of HTML represents the granularity of changes that partitions changes code. Given this test case, understanding the cause of failure into n partitions. For example, if the granularity is 2, it tries All Windows 3.1Windows 95Windows 98 Windows ME Windows2000 Windows NT Mac System 7 Mac System 7.5 Mac System 7.6.1 Mac System8.0 Mac System 8.5 Mac Syst em 8.6 Mac System 9.xMacOS XLinux BSDI FreeBSDNetBSDOpenBSD AIX BeOS HP-UXIRIXNeutrino OpenVMS OS/2 OSF/1 SolarisSunOSother -- P1 P2P3P4 P5 blocker criticalmajor normalminortrivial enhancement Figure 1: A snippet of a HTML file that caused a crash in Mozilla printing. to see if application/removal of half of changes can make a two states of a program and identifying the variables which passing test case to either to fail or vice versa. It recursively contribute to a failure of the program as causes of the failure. 0 0 narrows the difference between cp and cf . Moreover, if a In Section 2.4, we outline a method that exploits the notion coarse granularity does not help to narrow down the gap be- of cause for fault localization. tween the passing and failing test cases, it increases the gran- ularity. In this algorithm function test(t) tries input t in the 2.3 Search in Space program. It can have three outputs, program passes (V ), pro- A program failure is the result of a chain of infection in 2 gram fails with similar failure to cf (X), or unknown (?). the program states that is manifested in the output, or ob- Initially, this algorithm is invoked with dd2(cp,cf , 2). served by the oracle. A program state is infected if the value of at least one variable in the state deviates from the expected Algorithm 2 dd2 algorithm to isolate failing causes, value. Finding what variables go wrong in a failing execution 0 0 dd2(cp ,cf ,n) of a program can be used in debugging. The program can be 0 0 sliced upon the infected variables and the cause of failure (i.e. Input: cp current passing test case, cf current failing test 0 fault) can be identified in the logic that processes the variable. case, and n, granularity of remaining δ’s between cp and 0 In the rest of this section, we look at a method that exploits cf (∆1..∆n). 0 the dd2 algorithm to find the set of infected variables. if ∃∆i such that test(cp ∪∆i) = X then 0 0 Zeller has devised HOWCOME [42], a technique to isolate dd2(cp , cp ∪∆i, 2) 0 variables that infect the program state, i.e. produce error that else if ∃∆i such that test(cf −∆i) = V then 0 0 leads to failure. Suppose there are two runs rf and rp of dd2(cf −∆i, cf , 2) 0 a program P, which rf fails and rp succeeds. Furthermore, else if ∃∆i such that test(cp ∪∆i) = V then 0 0 let assume states of rf and rp at a location L is captured by dd2(cp ∪∆i, cf , max(n − 1, 2)) 0 memory graphs [44] Gf and Gp. HOWCOME uses dd2 algo- else if ∃∆i such that test(cf ∆i) = X then 0 0 rithm, presented in Section 2.2, to Gf and Gp to find minimal dd2(cp , cf −∆i, max(n − 1, 2)) else if n < ∆ then changes to Gp that makes rp to fail. A memory graph is a di- 0 0 rected graph in which its vertices contain values and types of dd2(cp , cf , min(2n, |∆|)) else program variables and arrows are labeled to denote opera- 0 0 tions such as de-referencing, and variable access. return (cp , cf ) end if HOWCOME assumes two vertices are matching in Gp and Gf , if either they have same types and values, or they are pointers of similar types which both contain NULL or both In case of the bug in the Mozilla Firefox if we assume the contains non-NULL values. Furthermore, two edges are match- c = and c is f p ing when their labels are similar and their source and desti- an empty string, the result of isolation is: nation vertices are matching. Two graphs can be matched by
• cf = adding and removing nodes. Figure 2 shows sample states of two executions of a program and the changes (δs) between • cp= SELECT NA=ty" MULTIPLE SIZE=7> them. HOWCOME uses the (approximate) largest common subgraph algorithm to match Gp and Gf graphs. It results a which the difference of the passing and failing test cases is set of atomic changes that transform Gp to Gf . HOWCOME “<” in the beginning of cf . The computational complexity of 2 uses each of these atomic changes as a δ in the dd2 algorithm. dd2 is O(|cf | ). ddmin and dd2 algorithms are powerful tools for under- When dd2 is run on Gp and Gf , it shows (1-)minimal changes standing failures hence improving the debugging process. These to the value of variables of Gpthat cause the resumption of rp algorithms also have been used for fault localization. In the to fail. In other words, they infect the state of the program Section 2.3, we explain how dd2 can be used for comparing that leads to the failure. Using this information, developers 2We assume two failures are similar, if they happen at similar could focus only on these values and inspect their impacts in location with similar stack of function call. the rest of the program, instead of spreading their attention 1 #include 2 #include 3 static void shell_sort(int a[], int size) 4 { 5 int i, j; 6 int h = 1; 7 do { 8 h = h * 3 + 1; 9 } while (h <= size); 10 do { 11 h /= 3; 12 for (i = h; i < size; i++) 13 { 14 int v = a[i]; Figure 2: Memory graphs for two execution of program, pos- 15 for (j = i; j >= h && a[j - h] > v; j -= h) sible changes. (Courtesy of [42].) 16 a[j] = a[j - h]; 17 if (i != j) 18 a[j] = v; to all of variables and values. 19 } Merits and Caveats. This approach does not require any in- 20 } while (h != 1); formation about the program, or developer intervention. Ap- 21 } plying HOWCOME at different locations in the program may 22 int main(int argc, char *argv[]) lead to different causes. Thus, one question is where the 23 { HOWCOME can be applied. Another issue is that, at a loca- 24 int i = 0; tion, there are potentially different sets of variables that can 25 int *a = NULL; be identified as causes. 26 a = (int *)malloc((argc - 1) * sizeof(int)); Running example. We use an implementation of the Shell 27 for (i = 0; i < argc - 1; i++) Sort in Figure 3 (taken from [14]) to illustrate the technique. 28 a[i] = atoi(argv[i + 1]); There is a bug in this program that resides at Line 30 where 29 the second argument to pass to shell_sort must be argc-1 30 shell_sort(a, argc); not argc. Suppose two executions of this program, F and 31 for (i = 0; i < argc - 1; i++) S. F invokes the program with “14 11” values and S with 32 printf("%d ", a[i]); “8 7 9”. Let Table 1 depict the contents of memory at Line 33 printf("\n"); 29 for the executions of F and S. In the execution of F , since 34 free(a); the value of a[2] is less than a[0], they are swapped and the 35 return 0; executions ends of with a wrong output “0 11”. In S, the 36 } value of uninitialized memory location at a[3] is greater than other elements of a, thus it is not swapped. If HOWCOME is run at Line 29, it would identify a[2] as the cause of failure. Figure 3: A buggy implementation of the Shell Sort. The reason is if we replace the content of a[2] in S with the content of a[2] is F, the execution of S would fail. that represent cause transitions in PDG, it measures the per- 2.4 Searching in Time cent of nodes in PDG which need to be examined to reach Faults in a program are places that infect the state of the the actual fault. The experiments, show that their technique program. HOWCOME, described in the previous section, is a is more accurate than previous technique called the nearest technique that tries to isolate (1-minimal) set of variables as neighborhood [39]. To make sense of the accuracy of this suspects for the failure at a location. Based on that, Cleve and technique, in almost half of cases, 40% or more of nodes in Zeller propose a heuristic to locate the faults [14]. the programs should be examined by developers before reach- HOWCOME compares states of failing and passing execu- ing to the node that represents the real fault. The authors tions of a program at different locations determines causes at hypothesize that some of the faults are hard to locate, like those locations. Wherever, the cause changes from adjacent variable initialization faults. statements sti−1 to sti, a “cause transition” has happened. Cleve and Zeller conjecture that sti’s that make a cause tran- 3. MODEL CHECKING FOR FAULT LOCAL- sitions are suspects to embody faults. For example, in the Shell sort example, in the previous section, HOWCOME iden- IZATION tifies argc as the cause for the failure at the beginning of In this section, first, we briefly introduce the concept of shell_sort function, thus there is a cause transition at Line model checking (Section 3.1). Then, in Section 3.2, we study 30. It differs from the cause at Line 29 (a[2]), therefore Line some techniques that locate faults using the results of model 30 is a suspicious statement for the failure. checking procedures. Merits and Shortcomings. This technique has been tested on Siemens test subjects [24], and could identify some of the 3.1 Model Checking seeded faults in them, and failed on some. The authors have Model checking is the problem of verifying a property φ in employed the program dependence graph (PDG) to evaluate a transition system R which models a system/program [12]. the accuracy of their technique. That is, starting from nodes Intuitively, R represents states of a system, and the transitions Table 1: Memory contents for the execution of S and F at Line 29 of the Shell Sort. argc argv[0] argv[1] argv[2] i a[0] a[1] a[2] a[3] F 3 14 11 NULL 2 14 11 0 1425 S 4 8 7 9 3 8 7 9 4215 between them. φ denotes a property of interest that we want that it cannot handle incidental correctness. That is, if a fault to investigate. Model checking procedures include sets of al- also appears in the passing trace, this technique fails to find it. gorithms to validate if model R holds the φ property. If R Another issue is using SLAM for implementation of this tech- violates φ, the model checking procedure returns a counter- nique. SLAM implements a model checking technique based example that details an example (i.e. a failure trace) in R that on predicate abstraction.The states of program with predicate leads to the violation of φ. Transition system R can repre- abstraction do not store concrete values of program variables, sent many software and hardware systems and property φ is instead they contain predicates on the values. This may add usually a temporal property that needs to be held by R. some infeasible traces to the set of correct traces, because Algorithmically, model checking techniques can be divided predicate abstraction does not check the validity of paths for into two categories: explicit state and symbolic. Explicit state the non-counter-examples. In this case, it is possible that fault model checking enumerates the reachable states from initial transitions be added to the set of correct transitions and this states in R explicitly. That is, it keeps the concrete value approach fails to identify them. of variables for each state. Symbolic model checkers encode Using Multiple Counter-examples states as boolean formulae. For this, symbolic model checkers The above technique relies on one counter-example that vio- may use Binary Decision Diagram (BDD) [9] or its variants lates the desired properties at a particular location. However, for concise encoding of formulae [13], or they may reduce it is possible that multiple counter-examples exist that vio- the problem of model checking to a SAT/SMT problem and late the properties at the same location. For that, Groce and utilize SAT/SMT solvers for the verification of properties [7]. Visser introduce the notion of negative and positive traces with Discussion about model checking and related topics is out of respect to a counter-example and propose transition analysis the scope of this paper; we refer the interested readers to [25] on the traces [21]. for a concise treatment of these topics. Set of negative traces (neg) with respect to a counter-example t that ends up with an error state se contains all traces that 3.2 Fault Localization Techniques start from initial states and end at se such that the control When a model checking procedure finds a violation of a de- location immediately before the se is similar to the control sired property in the transition system of a program, it returns location in t. In other words, neg(t) contains all counter- a counter-example, which is a failing trace of the program. In examples that violate same property, similarly. Likewise, a set this section, we study several techniques that use a counter- of positive traces (pos) w.r.t. t is defined, except that they example in a model which try to locate the faults in the mod- take the control location immediately before the se but they el/program. In Section 3.2.1, we look at one of the first tech- proceed. Moreover, they are not prefix to any of traces in neg. niques in the area that contrasts the transitions in one or mul- Given pos and neg, this technique analyzes the transitions. tiple counterexamples with passing traces. In Section 3.2.2, The analysis forms two groups all and only for each set. we glance at techniques that given a counter-example, at- all(pos) denotes transitions that exist in in all traces in pos. tempt to build the closest passing trace to the counter-example. Similarly all(neg) contains transitions that appear in all traces These methods are in a sense similar to delta debugging, but in neg. only(pos) denotes transitions in all(pos) but not in they are trying to build similar traces. Contrasting failing and any trace in neg. Likewise, only(neg) is the set of transitions passing traces can help to find suspicious transitions. Finally, in all(neg) but not in any of traces in pos. Section 3.2.3, describes a reduction of fault localization prob- To illustrate this technique, Figure 4 depicts a snippet of a lem to Max-SAT problem. program that, iteratively, takes a lock randomly, and releases it. A desired property in this program is: “lock can be re- 3.2.1 Contrasting Counterexamples with correct traces leased, if it has been acquired.” The fault in this program resides on the Line 9 where it should be inside the scope of Using a Single Counter-example the second if-statement. A counter-example for this program Ball et al. devised a technique for fault localization relying is 1 → 2 → 3 → 7 → 9 → 10 → 3 → 7 → 8 → Error. on the premise that execution of the fault is necessary for the software failure [5]. In their technique, whenever a counter- • all(neg) = {1, 2, <3,F>, 7, 8, 9 } example was found, it finds all traces that conform to the property (passing traces). Then, by contrasting transitions in • all(pos)= { 1,2, <3,T>,4,5,7,8 } the passing traces and the counter-example, the faults that led • only(neg) = {<3,F>, 9} to the deviation from the property are found and reported as a fault. Furthermore, if the program contains several faults, • only(pos) = { } those faults that already have been found are replaced by the halt statement. Halt statement semantically stops the exe- The technique uses the definition of all and only to define cution of the program, thus if a trace leads to a fault, it would the cause of failure as the transitions in both all(neg) and not be resumed to avoid the error. only(neg). That is, transitions that all traces of neg(t) and Merits and Shortcomings. This technique has been imple- did not appear in any of passing traces. Given the above val- mented in the SLAM [4] model checker. It has been experi- ues for all’s and only’s, the cause of failure is determined as mented on some Windows device drivers. Its major caveat is the set of transitions: cause(neg) = {<3,F>, 9}. cause(neg) 1 int got_lock = 0; 1 int main(){ 2 while(true){ 2 int input1, input2, input3; 3 if(random(2) == 0){ 3 int least = input1; //least#0 4 lock(); 4 int most = input1; //most#0 5 got_lock++; 5 if(most < input2) //guard#1 6 } 6 most = input2; //most#1,2 7 if(got_lock !=0) 7 if(most < input3) //guard#2 8 unlock(); 8 most = input3; //most#3,4 9 got_lock --; 9 if(least > input2) //guard#3 10 } 10 most = input2; //most#4,5 11 if(least > input3) //guard#4 12 least = input3; //least#1,2 Figure 4: Example 13 assert (least <= most); 14 } identifies the cause of the failure as a combination of not tak- ing the first if-statement and execution of statement Line 9. Figure 5: Buggy Minmax program, courtesy of [18]. Merits and Shortcoming. This method has been implemented in Java PathFinder. It could find the cause of an error in input1 = 1 a buggy version of DEOS real-time operating system. This input2 = 0 techique also suffers from incidental correctness problem. That input3 = 1 is, if the fault can appear in passing traces and failing traces, least#0= 1 this technique is not helpful. most#0 = 0 \guard#1 = false 3.2.2 Distance Metrics most#1 = 0 Given a counter-example, Groce proposed a technique to most#2 = 1 find the closest passing trace to the counter-example [17, 20, \guard#2 = false 19, 18]. Distance between a failing trace (i.e. counterex- most#3 = 1 ample) a and a passing trace b is defined as the number of most#4 = 1 differences between a and b. This algorithm has been im- \guard#3 = true plemented in explain tool [20]. explain uses the bounded most#5 = 0 model checker CBMC3. Figure 5 shows a version of minmax most#6 = 0 program that intended to find the minimum and maximum of \guard#4 = false three input variables. It includes an assertion that states the least#1 = 1 value of minimum must be less than or equal to the maximum least#2 = 1 value. The fault is at Line 10, where the correct assignment is least = input2. Figure 6 depicts a counter-example for the minmax program. Figure 6: counterexample for minmax in Figure 5 Given a counterexample a for a program P that violates as- sertion p, explain transforms P to SSA format such that each a variable is defined (i.e. assigned) only once. The comments v2∆ = (v2! = v2 ) in the Figure 5 show variables to be added for SSA format. ... a If P includes loops, P are unwound to the length of a plus vn∆ = (vn! = vn). a small constant integer. To find a passing trace that does For example, input1#0∆ ==(input1#0 ! = 1). Obviously, not violate the assertion, it is sufficient to conjunct a propo- the above constraints would not affect the result of the satis- sitional formula for P , say symb(P ) with the assertion p, i.e. fiablity problem. Afterwards, explain uses a Pseudo-Boolean symb(P ) ∧ p. Any satisfiable valuation to this formula would Solver (PBS) to solve the resulting formula. PBS is simi- be a passing trace for P . lar to SAT/SMT solvers except it accepts formulas in form Then, explain adds a set of constraints that represent the Σwi.bi ./ k where ./ is either of {<, >, ≤, ≥, =} and tries difference between a and the passing traces. If the variables to solve it. bi is a boolean variable and, wi and k are constant of the SSA format of P have values: values. explain chooses bi = vi∆ and wi = 1. Then, starting a v1 = v1 from k = 1, it incrementally increases the k and invokes the a v2 = v2 PBS until it finds a valuation that satisfies symb(P ) ∧ p and ... the constraints on ∆’s. The result is a passing trace, say b that a vn = vn its distance to a is k. The difference of a and b is reported to The related constraints would look like: the programmer . For example, Figure 7 shows resutls of ap- a v1∆ = (v1! = v1 ) plication of this technique to the minmax program. It shows that in the nearest passing trace, the result of guard#3 is not 3CBMC verifies safety properties in C programs. It constructs true, meaning that branch at Line 9 is not taken and respec- a propositional formula (say M) that represents the transition tively Line 10 is not executed. It can lead developers to Line system of the program. If a program contains loops, CBMC unwinds loops for a particular number of iterations. To verify 10. assertion p, the negation of p is conjuncted to M. If M ∧ ¬p A potential problem in using SSA format of program in def- is satisfiable, it means that there is a counterexample that inition of ∆’s is that it may count variables that are not ex- violates the p, otherwise the program satisfies the property. ecuted in the program. To address this, explain introduces Value changed: input2 from 0 to 1 Control location deleted (step #5): Value changed: most#1 from 0 to 1 10: most = input2 guard changed: least#0 > input2#0 (\guard#3) was TRUE {most = [ $0 == input2 ]} Value changed: most#5 from 0 to 1 ------Value changed: most#6 from 0 to 1 Predicate changed (step #5): was: most < least now: least <= most Figure 7: Result of execution of explain on the minmax Predicate changed (step #5): was: most < input3 now: input3 <= most ∆-slicing which slices the parts of programs that are not exe------cuted or are not related to assertion p. Predicate changed (step #6): Merits and Shortcoming. explain has been experimented was: most < least 4 on some versions of Tcas program from Siemens test sub- now: least <= most jects [24] and also on a micro-kernel. It was compared to Action changed (step #6): nearest neighborhood method [39] that is a spectra-based was: assertion failure fault localization technique. The results show that in some ------cases it outperforms the nearest neighborhood technique. The basic underlying caveat of this techniques is that it relies on symbolic model checking and PBS that hardly scale to large Figure 8: distance of a passing trace and counter-example in programs. abstract terms for minmax program.(Courtesy [11]) Abstract Counterexamples Predicate abstraction model checking relies on the fact that not all components of a program are involved in a specific Then, the difference between two traces a and b is defined property. Therefore, instead of considering values of all vari- as d(a, b) = Wp.∆p(a, b)+Wα.∆α(a, b))+Wc.∆c(a, b), where ables in the program, it stores a set of predicates on the state ∆p(a, b) denotes the total number of predicate differences in of the program that actually affect the property under inves- all aligned states and ∆α(a, b) is the total number of differ- tigation. It helps scaling up model checking for larger pro- ences in actions in the aligned states. ∆c(a, b) denotes the grams.(See [34, 4] for further details.) total number of states that are not aligned. Wp,Wα and Wc In [11], explain has been extended to predicate-based ab- are weights for each of those terms. For the sake of minimiz- stract counter-examples. The new technique has been imple- ing the difference of states, the weights have been chosen as a mented on top of MAGIC [10] model checker.The new algo- Wp = Wα = 1 and Wc = max(|p(s )|) + 2. Afterwards, rithm is the same as explain, except for comparison of fail- d(a, b) is added to the transition relation as in explain and a ing and passing traces it uses predicates. But this comparison PBS is used to minimize the difference of a and b. Figure 8 is is not straightforward like ∆’s in SSA, because at each con- the result of using this technique on the bug in the minmax trol location, MAGIC may keep different predicates. Thus, program. the new technique attempts to align the states of passing and Shortcomings and Strengths. Good predicates provide a failing counterexamples such that they can be comparable. higher level explanation of the failure and there are more in- States in predicate abstraction are like {(s1, α1), (s2, α2), ..., tuitive. Essentially, it can summarize the conditions under (si, αi), ...}, where si is composed of predicates at state i and which a program fails. Moreover, model checking with pred- αi represents transition in state i. c(si) denotes the control icate abstraction usually scales better than model checking location on state si, furthermore pj (si) denotes the jth pred- without abstraction. On the other hand, predicate abstraction icate in si. may need numerous iterations adding numerous predicates to The alignment is defined as follows and assures the states states in order to produce a passing traces. It may result a con- are aligned if they are comparable. The alignment is one- junction of several predicates to explain the counter-example to-one and it preserves the order of states in the transitions which it is not necessarily helpful. This technique has been system. used for faulty versions of some small programs (upto 350 LOC) and some moderate size of code ( 3 KLOC). 8 >1 if (c(si) = c(sj )∧ 3.2.3 Reduction to Max-SAT > > align(i, k) = 0 for k 6= j ∧ k ≤ |b|∧ Propositional representation of program traces has facili- > <> align(k, j) = 0 for k 6= i ∧ k ≤ |a|∧ tated reduction of various program analysis and verification align(i, j) = align(m, n) = 0 for m < i ∧ n > j∧ to propositional logic problems (See [8, 6, 33]). In this sec- > tion, we look at reduction of fault localization to Max-SAT > > align(m, n) = 0 for m > i ∧ n < j problem. > :0 otherwise The counter-example includes an input data that leads to the violation and the trace. Using the program specification The unalignment is defined as not being aligned. (say p), a failing output (I) and the corresponding symbolic unaligend (i) = ¬ W align(i, j) a encoding of trace of the failing input(SP (I)), Jose and Ma- unaligend (j) = ¬ W align(i, j) b jumdar has built BugAssist that reduces the problem of fault 4Tcas is a program for traffic collision avoidance in avionic localization to the Max-SAT problem [28, 27]. system. An implementation of it that is available at Siemens Max-SAT problem is the problem of finding a valuation for a test subject is a popular test subject. SAT formula that satisfies the maximum number of clauses in int Array[3]; for fault localization. On the downside, it suffers from the int testme(int index) problem of scalability that all of symbolic techniques suffer. { However, it suggests using dynamic symbolic techniques or if ( index != 1) /* Potential Bug 2 */ slicing, delta debugging to reduce the size of propositional index = 2; formulae or failing traces. BugAssist has been experimented else on Tcas program of the Siemens test subject and on avarage index = index + 2; /* Potential Bug 1 */ it could reduce the search space for the fault to 8% of the i = index; program. assert(i >= 0 && i < 3); return Array[i]; } 4. DISCUSSION In this paper, we have looked at two different approaches to fault localization. In this section, we discuss the viability of Figure 9: sample program these approaches. First, we revisit the goal of fault localiza- tion and relate them with the techniques that we studied in this paper. Finally, we discuss about a type of fault that is not the formula. Max-SAT problem, like 3-SAT problem, is an NP- addressed by the techniques presented in this paper, missing hard problem and like SAT-Solvers, several Max-SAT solvers component fault. exist. As a result, Max-SAT solvers also show the clauses that are not satisfied by the proposed valuation. The set of 4.1 Goal of Automated Fault Localization clauses that are not satisfied by the valuation is called mini- Automation of fault localization techniques intends to facil- mal “UNSAT-core” of the formula. An un-satisfiable formula itate and accelerate debugging by finding the suspicious com- can have several UNSAT-cores. ponents of programs. A large portion of software develop- An interesting feature of modern Max-SAT solvers is the ment (35% according to [31]) is spent on navigating through ability to allow users to divide the constraints (i.e. clauses) programs for maintenance. Thus, there is an opportunity for in the formula into two categories: soft and hard. Hard con- the automated fault localization techniques to reduce that. straints denote the constraints that must be satisfied by the Their success in this mission depends on their effectiveness valuation and soft constraints are those constraints that can and efficiency. be left unsatisfied. It should be recalled that in SAT problems all constraints must be satisfied. Furthermore, some Max-SAT 4.1.1 Effectiveness solvers let users to associate weights to clauses and they at- An effective fault localization technique should point to the tempt to maximize the total weight of satisfied clauses. places that actual faults reside and provide some clues for Given a program and a failing input, BugAssist generates fixing the fault. In short, it should be precise, and informative. the symbolic representation of the trace of the failure(say P ), then it builds the propositional formula I ∧ P ∧ p . where Precision I is a formula that denotes the input of program and p is Precision demands low false negatives. The output of an FL the specification of program. BugAssist makes constraints I technique should not confuse developers by pointing to too and p hard constraints and P constraints are soft constraints. many different, irrelevant components of a program as sus- That is, the Max-SAT solver must find the minimal UNSAT- pects of a failure. Current automated FL techniques usually CORE within P . UNSAT-cores are the cause of unsatisfiability either produce a set of suspicious statements without any par- of the formula, hence we can assume that there are reasons ticular ranking, or they devise a suspiciousness factor and for program failure. For example, consider the program in then rank all statements according it. The techniques that Figure 9. It fails for input index = 1. Thus, in this program we described in this paper fit in the first category; they just I = (index == 1), the specification is p = (i ≥ 0∧i < 3), and give a set of suspicious statement and do not rank them. P = (index1 == 1 ∧ index2 == index1 + 2 ∧ i == index2), There are two major metrics that researchers use to evalu- where I and p are hard constraints. The UNSAT-core of this ate the FL techniques. One metrics assumes that statements example is index2 == index1 + 2. The inspection of the are ranked by suspiciousness. The precision of the technique corresponding statement and related statements can lead us is the percent of statements in the program that must be ex- to the fault. amined to reach the fault, starting from the most suspicious An UNSAT-core might be incomplete or insufficient to ex- statement [26,2]. The other metric uses program dependence plain the program failure. Thus, BugAssist employs an iter- graph (PDG) [23] to evaluate FL techniques. That is, given a ative process that uses the feedback from the user. For this, suspicious statement, the percentage of nodes in PDG that when the Max-SAT procedure in BugAssist finds an UNSAT- needs to be examined to reach the fault node determines the core u of the formula, it reports it to the user. The user in- accuracy of a method [39, 14]. It is worth mentioning that spects u as clue for debugging, if she found it useless for de- a recent study [38] has shown that developers, on average, bugging, she asks for another UNSAT-core. BugAssist adds u only pay attention to the first 10 suggestions of FL techniques to the hard constraints and then reruns the Max-SAT proce- and would dismiss the rest of results. In other words, an au- dure. tomated FL technique is useful if the actual fault is in its 10 Merits and shortcoming. Perhaps the most significant con- first suggestions. tribution of BugAssist is the reduction of fault localization to . Max-SAT problem and using off-the-shelf solvers to solve it. Another contribution is that it needs only a failing trace and Informativeness the corresponding input to form the corresponding Max-SAT Although identifying some statements as suspects for a fail- formulation. In other word, it does not need passing traces ure reduces the search space for debugging, it barely helps developers to design a fix for the program. In other words, 4.2 Missing Component each suspicious statement is a hypothesis about the location Software faults can be partitioned into two broad categories: of fault and it would be better to accompany with the justifi- wrong algorithmic component and missing component. While cations about why the FL technique has inferred a component the former has to do with statements that are faulty (e.g. us- as the potential bug. Given such information, developers can ing wrong operator), the latter characterizes situations when add their own knowledge about the program to decide if a a piece of program logic is missing (e.g. missing an assign- particular location is the cause of the failure and if so, what ment statement, or a conditional statement). A study of real would be the best fix for that? faults in some open source project has shown that the missing In the cause transition technique, Section 2.4, the hypoth- component faults constitutes 64% of real faults [16]. Majority esis is backed with the fact that a cause transition has hap- of proposed techniques attempt to find the wrong algorithmic pened at a location. Techniques using contrasting, Section component faults. Thus, there is a need to devise techniques 3.2.1 justify selection based on absence of a transition in a to address these faults. passing trace. Likewise, BugAssist in Section 3.2.3, just relies on the fact that the suspicious statement appear in the UNSAT- core of the trace formula. Although all of these justifications 5. REFERENCES seem appealing, they are easy to refute; e.g. it is possible if [1]A GRAWAL,H., AND HORGAN, J. R. Dynamic program we try different inputs we get different cause transitions, or a slicing. In Proceedings of the ACM SIGPLAN 1990 faulty transition can appear in some passing traces. We wish conference on Programming language design and to have a better explanation of the participation of a poten- implementation (New York, NY, USA, 1990), PLDI ’90, tial fault in a failure. The technique for explaining abstract ACM, pp. 246–256. counter-examples, described in Section 3.2.2, has the advan- [2]A LI,S.,ANDREWS,J.,DHANDAPANI,T., AND WANG, tage of summarizing the failure in higher abstraction (pred- W. Evaluating the accuracy of fault localization icates on program variables) than other techniques. We do techniques. In Automated Software Engineering , 2009. no know the most suitable level of abstraction for explaining ASE ’09. 24th IEEE/ACM International Conference on failures or justifying a fault at a particular location; e.g. if a (nov. 2009), pp. 76 –87. chain or series of why questions [32,30] the best. But it seems [3]B AAH,G.K.,PODGURSKI,A., AND HARROLD,M.J. reasonable to expect fault localization techniques to augment Mitigating the confounding effects of program suspicious program components with the information about dependences for effective fault localization. In how they could have contributed to the error. Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software 4.1.2 Efficiency engineering (New York, NY, USA, 2011), ESEC/FSE ’11, Software debugging should be performed timely, within the ACM, pp. 146–156. timing and budgeting constraints. This constraint also applies [4]B ALL,T.,LEVIN, V., AND RAJAMANI, S. A decade of to fault localization as well. It should be efficient. We identify software model checking with slam. Communications of two metrics for efficiency: scalability, and information usage. the ACM 54, 7 (2011), 68–76. Scalability [5]B ALL,T.,NAIK,M., AND RAJAMANI, S. K. From symptom to cause: localizing errors in counterexample As we have seen in this paper, the techniques vary in their traces. In Proceedings of the 30th ACM SIGPLAN-SIGACT scalability. The methods based on model checking and sym- symposium on Principles of programming languages bolic execution, Section 3, suffer from scalability. That is they (New York, NY, USA, 2003), POPL ’03, ACM, cannot be used for large programs. On the other hand, delta pp. 97–105. debugging techniques are able to scale better. [6]B IERE,A. Handbook of satisfiability, vol. 185. Ios Information Usage PressInc, 2009. [7]B IERE,A.,CIMATTI,A.,CLARKE,E., AND ZHU, Y. Each fault localization technique needs some information from Symbolic model checking without bdds. Tools and the program for its processing. It consumes this information Algorithms for the Construction and Analysis of Systems to infer locations of faults. There are two dimensions on the (1999), 193–207. information consumption: what it needs to start with, and [8]B RADLEY,A., AND MANNA,Z. The calculus of what it can exploit to boost its precision or performance. computation: decision procedures with applications to Techniques based on delta debugging, require little knowl- verification, vol. 374. Springer, 2007. edge about the program and specification; they can started [9]B RYANT, R. Graph-based algorithms for boolean from a failing input and passing input, which are usually avail- function manipulation. Computers, IEEE Transactions on able. On the other hand, techniques based on model check- 100, 8 (1986), 677–691. ing need formal specification of programs to be able to work, which is unlikely to exist for all programs. [10]C HAKI,S.,CLARKE,E.,GROCE,A.,JHA,S., AND In addition to a program itself, there are many other sources VEITH, H. Modular verification of software components of information that can be used; e.g. change history, devel- in c. Software Engineering, IEEE Transactions on 30, 6 opers, and found errors. Each of these can be exploited to (2004), 388–402. enhance the fault localization. For example, we may be able [11]C HAKI,S.,GROCE,A., AND STRICHMAN, O. Explaining to enhance fault localization by identifying components with abstract counterexamples. ACM Sigsoft Software complex behaviors; these components may be identified by Engineering Notes 29 (2004), 73–82. their developers or comments in the program. We have not [12]C LARKE,E.,GRUMBERG, O., AND PELED,D. Model seen usage of such information in any of techniques that de- checking. MIT press, 2000. scribed in this paper. [13]C LARKE,E.,MCMILLAN,K.,CAMPOS,S., AND Verification (2011), Springer, pp. 504–509. HARTONAS-GARMHAUSEN, V. Symbolic model [28]J OSE,M., AND MAJUMDAR, R. Cause clue clauses: checking. In Computer Aided Verification (1996), error localization using maximum satisfiability. In Springer, pp. 419–422. Proceedings of the 32nd ACM SIGPLAN conference on [14]C LEVE,H., AND ZELLER, A. Locating causes of program Programming language design and implementation (New failures. In Proceedings of the 27th international York, NY, USA, 2011), PLDI ’11, ACM, pp. 437–446. conference on Software engineering (New York, NY, USA, [29]K ATZ,I.R., AND ANDERSON, J. R. Debugging: an 2005), ICSE ’05, ACM, pp. 342–351. analysis of bug-location strategies. Hum.-Comput. [15]D EMILLO,R.A.,PAN,H., AND SPAFFORD, E. H. Critical Interact. 3, 4 (Dec. 1987), 351–399. slicing for software fault localization. ACM Sigsoft [30]K O,A., AND MYERS, B. Debugging reinvented. In Software Engineering Notes 21 (1996), 121–134. Software Engineering, 2008. ICSE ’08. ACM/IEEE 30th [16]D URAES,J., AND MADEIRA, H. Emulation of software International Conference on (may 2008), pp. 301 –310. faults: A field data study and a practical approach. [31]K O,A.,MYERS,B.,COBLENZ,M., AND AUNG, H. An Software Engineering, IEEE Transactions on 32, 11 (nov. exploratory study of how developers seek, relate, and 2006), 849 –867. collect relevant information during software [17]G ROCE, A. Error explanation with distance metrics. maintenance tasks. Software Engineering, IEEE Tools and Algorithms for the Construction and Analysis of Transactions on 32, 12 (2006), 971–987. Systems (2004), 108–122. [32]K O,A.J., AND MYERS, B. A. Finding causes of [18]G ROCE,A. Error Explanation and Fault Localization program output with the java whyline. In Proceedings of with Distance Metrics. PhD thesis, Carnegie Mellon the SIGCHI Conference on Human Factors in Computing University, 2005. Systems (New York, NY, USA, 2009), CHI ’09, ACM, [19]G ROCE,A.,CHAKI,S.,KROENING,D., AND pp. 1569–1578. STRICHMAN, O. Error explanation with distance [33]K ROENING,D., AND STRICHMAN, O. Decision metrics. International Journal on Software Tools for procedures: an algorithmic point of view. Springer, 2008. Technology Transfer (STTT) 8, 3 (2006), 229–247. [34]K URSHAN,R. Computer-aided verification of [20]G ROCE,A.,KROENING,D., AND LERDA, F. coordinating processes: the automata-theoretic approach. Understanding counterexamples with explain. In Princeton university press, 1995. Computer Aided Verification (2004), Springer, [35]L AWRANCE,J.,BOGART,C.,BURNETT,M.,BELLAMY, pp. 318–321. R.,RECTOR,K., AND FLEMING, S. How programmers [21]G ROCE,A., AND VISSER, W. What went wrong: debug, revisited: An information foraging theory explaining counterexamples. In Proceedings of the 10th perspective. Software Engineering, IEEE Transactions on international conference on Model checking software PP, 99 (2010), 1. (Berlin, Heidelberg, 2003), SPIN’03, Springer-Verlag, [36]L IBLIT,B.,AIKEN,A.,ZHENG,A.X., AND JORDAN, pp. 121–136. M. I. Bug isolation via remote program sampling. In [22]G YIMÓTHY,T.,BESZÉDES,A., AND FORGÁCS, I. An Proceedings of the ACM SIGPLAN 2003 conference on efficient relevant slicing method for debugging. In Programming language design and implementation (New Proceedings of the 7th European software engineering York, NY, USA, 2003), PLDI ’03, ACM, pp. 141–154. conference held jointly with the 7th ACM SIGSOFT [37]L IU,C.,YAN,X.,FEI,L.,HAN,J., AND MIDKIFF, S. P. international symposium on Foundations of software Sober: statistical model-based bug localization. In engineering (London, UK, 1999), ESEC/FSE-7, Proceedings of the 10th European software engineering Springer-Verlag, pp. 303–321. conference held jointly with 13th ACM SIGSOFT [23]H ORWITZ,S., AND REPS, T. The use of program international symposium on Foundations of software dependence graphs in software engineering. In IN engineering (New York, NY, USA, 2005), ESEC/FSE-13, PROCEEDINGS OF THE FOURTEENTH INTERNATIONAL ACM, pp. 286–295. CONFERENCE ON SOFTWARE ENGINEERING (1992), [38]P ARNIN,C., AND ORSO, A. Are automated debugging pp. 392–411. techniques actually helping programmers? In [24]H UTCHINS,M.,FOSTER,H.,GORADIA,T., AND Proceedings of the 2011 International Symposium on OSTRAND, T. Experiments of the effectiveness of Software Testing and Analysis (New York, NY, USA, dataflow- and controlflow-based test adequacy criteria. 2011), ISSTA ’11, ACM, pp. 199–209. In Proceedings of the 16th international conference on [39]R ENIERES,M., AND REISS, S. Fault localization with Software engineering (Los Alamitos, CA, USA, 1994), nearest neighbor queries. In Automated Software ICSE ’94, IEEE Computer Society Press, pp. 191–200. Engineering, 2003. Proceedings. 18th IEEE International [25]J HALA,R., AND MAJUMDAR, R. Software model Conference on (oct. 2003), pp. 30 – 39. checking. ACM Comput. Surv. 41, 4 (Oct. 2009), [40]R EPS,T.,BALL,T.,DAS,M., AND LARUS, J. The use of 21:1–21:54. program profiling for software maintenance with [26]J ONES,J.A.,HARROLD,M.J., AND STASKO,J. applications to the year 2000 problem. In Proceedings of Visualization of test information to assist fault the 6th European SOFTWARE ENGINEERING conference localization. In Proceedings of the 24th International held jointly with the 5th ACM SIGSOFT international Conference on Software Engineering (New York, NY, symposium on Foundations of software engineering (New USA, 2002), ICSE ’02, ACM, pp. 467–477. York, NY, USA, 1997), ESEC ’97/FSE-5, Springer-Verlag [27]J OSE,M., AND MAJUMDAR, R. Bug-assist: assisting New York, Inc., pp. 432–449. fault localization in ansi-c programs. In Computer Aided [41]W EISER, M. Program slicing. In Proceedings of the 5th [43]Z ELLER,A., AND HILDEBRANDT, R. Simplifying and international conference on Software engineering isolating failure-inducing input. IEEE Trans. Softw. Eng. (Piscataway, NJ, USA, 1981), ICSE ’81, IEEE Press, 28 (February 2002), 183–200. pp. 439–449. [44]Z IMMERMANN,T., AND ZELLER, A. Visualizing memory [42]Z ELLER, A. Isolating cause-effect chains from computer graphs. In Software Visualization, S. Diehl, Ed., programs. In SIGSOFT ’02/FSE-10: Proceedings of the vol. 2269 of Lecture Notes in Computer Science. Springer 10th ACM SIGSOFT symposium on Foundations of Berlin / Heidelberg, 2002, pp. 533–537. software engineering (New York, NY, USA, 2002), ACM, 10.1007/3-540-45875-1. pp. 1–10.
