Explaining Inconsistent Code. Muhammad Numair Mansur

Transcription

1 Explaining Inconsistent Code Muhammad Numair Mansur

2 Introduction 50% of the time in debugging Fault localization. Becomes more tedious as the program size increase. Automatically explaining and localizing inconsistent code. 2

3 Code Inconsistency A code fragment is inconsistent if it is not a part of any normally terminating execution. Not necessarily always a bug! But sometimes inconsistent code results in an error. 3

4 Examples (Unreachability) Generated using Bixie 4

5 Examples (Unreachability) Generated using Bixie 5

6 Examples (conflicting assumptions) Generated using Bixie 6

7 Examples (conflicting assumptions) Generated using Bixie 7

8 Our Goal Automatically explain inconsistent code. 8

9 Our Goal Automatically explain inconsistent code. Pre Inconsistent program Automata Algorithm Error Invariant Automaton Post 9

10 Our Goal Automatically explain inconsistent code. Pre Inconsistent program Automata Algorithm Error Invariant Automaton Post 10

11 Finite automata A F.A is a 5 tuple: (Q, Σ, δ, q o,f) Q: A finite set of states. Σ: A finite set of input symbols called an alphabet. δ: A transition function ( δ: Q x Σ Q ). q : initial state. o F: A finite set of final states. 11

12 Finite automata Example: S 1 S 2 S 3 S 4 12

13 Finite automata Example: S 1 States S 2 S 3 S 4 13

14 Finite automata Example: S 1 States Transitions S 2 S 3 S 4 14

15 Finite automata input (A sequence from the input alphabet) F.A Output (accept or reject) Transitions through the states based on the input True, if ends in an accepting state 15

16 Finite automata Example: S 1 Σ = {a,b,c} Input: abca S 2 S 3 S 4 16

17 Finite automata Example: Σ = {a,b,c} Input: abca S 1 a S 2 S 3 S 4 17

18 Finite automata Example: Σ = {a,b,c} Input: abca S 1 a S 2 S 3 b S 4 18

19 Finite automata Example: Σ = {a,b,c} Input: abca S 1 a S 2 S c 3 b S 4 19

20 Finite automata Example: Σ = {a,b,c} Input: abca S 1 a S 2 S c 3 a b S 4 accept! 20

21 Program automata A simple and an abstract model of a program. 21

22 Program automata A simple and an abstract model of a program. Defined in terms of a finite automata. State (Q) = Program Location (Loc) Transition (δ) = Program Statement (δ p ) Alphabet(Σ) = A set of program statements Initial State (q 0 ) = Initial program Location ( ) Final State ( F ) = Final program Location ( ) 22

23 Program automata 23

24 Program automata assume( b ) means that the branch of if () is taken where b is true assume(!b ) means that the branch of if () is taken where b is not true 24

25 Program automata An assertion on the program state that x!= null 25

26 Program automata A run ρ is a finite sequence of locations and statements. l o st o l 1..st n-1 l n A path(ρ) st o st 1.. st n-1 is the path associated with a run. A run ρ is accepting if its final state is l e A word π * is a path if π = path(ρ) for some accepting run ρ. 26

27 Our Goal To automatically explain inconsistent code. Pre Inconsistent program Automata Algorithm Error Invariant Automaton Post 27

28 Algorithm Input: : precondition state formula : program automata : Postcondition state formula output: : error invariant automata. requires: is inconsistent subject to ensures: explains and.. 28

29 Algorithm Step 1: Translate the program automata into a single path of statements π. 29

30 Algorithm Step 1: Translate the program automata into a single path of statements π. 30

31 Algorithm Step 1: Translate the program automata into a single path of statements π. It can be composed of many atomic statements. 31

32 Algorithm Example: , This was the first step in getting the final result, an error invariant automata. 32

33 Error Invariant Automaton An abstraction of the program, that only mentions the statements and facts that are relevant for understanding the cause of the inconsistency. The irrelevant statements are first summarized as first order logical formulas and then eliminated. These formulas are called error invariants. An error invariant captures the reason of abnormal program termination. So, at a high level, an Error Invariant Automaton replaces code which does not contribute to the inconsistency with a suitably chosen invariant. Lets see this in practice on a fragment of code. 33

34 Error Invariant Automaton 1: public TaskDialog(Tast task) ~: : txtdescription.settask(task.getdescription()); ~: : if (notification) {..... } ~: : chbregular.setenabled(task == null); ~:.... } 34

35 Error Invariant Automaton 1: public TaskDialog(Tast task) ~: : txtdescription.settask(task.getdescription()); ~: : if (notification) {..... } ~: : chbregular.setenabled(task == null); ~:.... line 1-5 line 7-26 line 6 line 27 No Effect on inconsistency assert ( task!= null ) Arbitrary code No effect on task == null An assertion that task might be null } line 28 - end No Effect on inconsistency 35

36 Error Invariant Automaton 1: public TaskDialog(Tast task) ~: : txtdescription.settask(task.getdescription()); ~: : if (notification) {..... } ~: : chbregular.setenabled(task == null); ~:.... line 1-5 line 7-26 line 6 line 27 No Effect on inconsistency assert ( task!= null ) Arbitrary code No effect on task == null An assertion that task might be null } line 28 - end No Effect on inconsistency 36

37 Error Invariant Automaton 1: public TaskDialog(Tast task) ~: : txtdescription.settask(task.getdescription()); ~: : if (notification) {..... } ~: : chbregular.setenabled(task == null); ~:.... line 1-5 line 7-26 line 6 line 27 No Effect on inconsistency assert ( task!= null ) Arbitrary code No effect on task == null An assertion that task might be null } line 28 - end No Effect on inconsistency 37

38 Error Trace An error trace is a sequence of statements π = st0st1... stn, together with. describes the initial state and and is an assertion that is violated. That means, in an error trace Λ PF( π ) Λ is unsatisfiable. 38

39 Error Trace An error trace is a sequence of statements π = st0st1... stn, together with. describes the initial state and and is an assertion that is violated. That means, in an error trace Λ PF( π ) Λ is unsatisfiable. Example: Λ task null Λ task null Λ 39

40 Error Invariant An error invariant for a position [ logical formula such that. ] in an error trace is a first order The conjunction of the first order logical formulas for each statement implies I i. I i and the conjunction of the remaining formulas is unsatisfiable. 40

41 ErrInv( ) In the previous work, the authors introduced a function given an error trace, computes: which I0,sti1,I1,sti2... stik,ik Such that, sti1, sti2..stik is a subsequence of and Ij is an inductive invariant for the position ij and ij+1. 41

42 Inductive error invariant We say that an error invariant is inductive for position i < j if : 42

43 Inductive error invariant We say that an error invariant is inductive for position i < j if : 43

44 Inductive error invariant We say that an error invariant is inductive for position i < j if : is called an inductive error invariant. 44

45 Error Invariant Automaton An Error Invariant Automaton is an inconsistent program automaton with a mapping from locations of to state formulas, such that for all locations, is an error invariant for. 45

46 Algorithm Now, after applying step 1 we got a single path π A. Step 2: Apply ErrInv( π A ) ErrInv(π A ) = ErrInv( π ) = I 0 st(l i1 ) st(l ik )I k.

47 Algorithm Now, after applying step 1 we got a single path π A. I0 I1 I2 Step 2: Apply ErrInv( π A ) ErrInv(π A) = ErrInv( π ) I3 = I0st(li1) st(lik)ik. I4 I5 47

48 Algorithm Now, after applying step 1 we got a single path π A. I0 I1 I2 Step 2: Apply ErrInv( π A ) ErrInv(π A) = ErrInv( π ) I3 = I0st(li1) st(lik)ik. error invariants I4 I5 48

49 Algorithm Example: assume(task!=null) assume(task =null) 49

50 Algorithm Example: true assume(task!=null) assume(task!=null) ErrInv() task!= null assume(task =null) assume(task =null) false 50

51 Algorithm Step 3: The locations covered with an inductive error invariant can be collapsed into a single location. I 0 I 0 I 1 I 1 I 0 I 1 I 4 I 4 I 5 I 5 51

52 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 I 1 I 2 I 52

53 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 I 1 Apply the algo recursively to these nonatomic statements I 2 I 53

54 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 In case of this location I 1 I 2 Pre Post I 54

55 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 In case of the location with invariant I 2 I 1 I 2 Pre Post Inconsistent w.r.t pre and post I 55

56 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 In case of the location with invariant I 2 I 1 I2 I 56

57 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 pre In case of the location with invariant I 2 I 1 recursively I 2 post I 57

58 Algorithm Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata. I 0 I 1 I I 2 I 58

59 Algorithm 1: public TaskDialog(Tast task) ~: : txtdescription.settask(task.getdescription()); ~: : if (notification) {..... } ~: : chbregular.setenabled(task == null); ~:.... } 59

60 Evaluations The approach was tested on 6 real world examples. For each of these examples, Error invariant automatas were generated using the technique introduced. All the generated error invariant automatas represented real world inconsistencies with no false alarms. Running time to prove inconsistency using unsat ranged from seconds in one of the experiments to seconds. 60

61 Evaluations Usability testing was also conducted on 11 programmers. Half of the test subjects were shown the full programs, while the other half were just shown the error invariant automata. All candidates took 1 hour and 6 minutes to identify the bug. For the full programs without error invariant automata : 51 minutes With error invariant automata : 17 minutes 61

62 Conclusion The experiments indicate that EIA provide useful visual assistance to spot inconsistencies. EIA can also be used for fault localization on a single trace and thus provide a general tool to assist programmers in debugging. 62

63 References Martin Schaf, Daniel Schawrtz, Thomas Wies Book Title: Joint meeting of the European Software Engineering conference and the Symposium on the Foundations of Software Engineering, ESEC/FSE 13, Saint Petersburg, Russian Federation, August18-26,2013 url: Title: Explaining Inconsistent Code, pages: Bixie - FInd inconsistencies in Java code. Jurgen Christ, Evren Ermis, Martin Schaf, Thomas Weis Book Title: Verification, Model Checking, and Abstract Interpretation,14th International Conference, VMCAI 2013, Rome, Italy, January 20-22, Proceedings url: Title: Flow-Sensitive Fault Localization, pages :