Explaining Inconsistent Code Muhammad Numair Mansur Introduction - - PowerPoint PPT Presentation

Explaining Inconsistent Code

Muhammad Numair Mansur

Introduction

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

2

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

Examples (Unreachability) Generated using Bixie

4

Examples (Unreachability) Generated using Bixie

5

Examples (conflicting assumptions) Generated using Bixie

6

Examples (conflicting assumptions) Generated using Bixie

7

Our Goal

Automatically explain inconsistent code.

8

Our Goal

Automatically explain inconsistent code.

9

Algorithm Inconsistent program Automata Error Invariant Automaton Pre Post

Our Goal

Automatically explain inconsistent code.

10

Algorithm Inconsistent program Automata Error Invariant Automaton Pre Post

Finite automata

A F.A is a 5 tuple: (Q, Σ, δ, qo,F)

Q: A finite set of states. Σ: A finite set of input symbols called an alphabet. δ: A transition function ( δ: Q x Σ → Q ). qo : initial state. F: A finite set of final states.

11

Finite automata

Example:

12

S1 S4 S2 S3

Finite automata

Example:

13

S1 S4 S2 S3 States

Finite automata

Example:

14

S1 S4 S2 S3 States Transitions

Finite automata

15

F.A

input

(A sequence from the input alphabet)

Output

(accept or reject)

• Transitions through the states based on the input
• True, if ends in an accepting state

Finite automata

16

S1 S4 S2 S3 Σ = {a,b,c} Input: abca

Example:

Finite automata

Example:

17

S1 S4 S2 S3 a Σ = {a,b,c} Input: abca

Finite automata

Example:

18

S1 S4 S2 S3 a b Σ = {a,b,c} Input: abca

Finite automata

Example:

19

S1 S2 S3 a b c Σ = {a,b,c} Input: abca S4

Finite automata

Example:

20

S1 S4 S2 S3 a b c a accept ! Σ = {a,b,c} Input: abca

Program automata

A simple and an abstract model of a program.

21

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 (q0) = Initial program Location ( ) Final State ( F ) = Final program Location ( )

22

Program automata

23

Program automata

24

assume( !b ) means that the branch of if () is taken where b is “not true” assume( b ) means that the branch of if () is taken where b is “true”

Program automata

25

An assertion on the program state that x != null

Program automata

• A run ρ is a finite sequence of locations and statements.

lo sto l1 …..stn-1 ln

• A path(ρ) sto st1 ….. stn-1 is the path associated with a run.
• A run ρ is accepting if its final state is le
• A word π ∈ * is a path if π = path(ρ) for some accepting run ρ.

26

Our Goal

To automatically explain inconsistent code.

27

Algorithm Inconsistent program Automata Error Invariant Automaton Pre Post

Algorithm

Input: : precondition state formula : program automata : Postcondition state formula

• utput:

: error invariant automata.

requires: is inconsistent subject to and . ensures:

explains .

28

Algorithm

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

29

Algorithm

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

30

Algorithm

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

31

It can be composed

• f many atomic

statements.

Algorithm

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

32

1 2 3 4 5 6 7 8 9 1 2

2,9

9

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

Error Invariant Automaton

1: public TaskDialog(Tast task) ~: . . . . . . 6: txtDescription.setTask(task.getDescription()); ~: . . . . . . 16: if (notification) { . . . . . } ~: . . . . 27: chbRegular.setEnabled(task == null); ~: . . . . }

34

Error Invariant Automaton

1: public TaskDialog(Tast task) ~: . . . . . . 6: txtDescription.setTask(task.getDescription()); ~: . . . . . . 16: if (notification) { . . . . . } ~: . . . . 27: chbRegular.setEnabled(task == null); ~: . . . . }

line 1 - 5 line 6 line 7 - 26 line 27 line 28 - end No Effect on inconsistency assert ( task != null ) Arbitrary code No effect on task == null An assertion that task might be null No Effect on inconsistency

35

Error Invariant Automaton

1: public TaskDialog(Tast task) ~: . . . . . . 6: txtDescription.setTask(task.getDescription()); ~: . . . . . . 16: if (notification) { . . . . . } ~: . . . . 27: chbRegular.setEnabled(task == null); ~: . . . . }

line 1 - 5 line 6 line 7 - 26 line 27 line 28 - end No Effect on inconsistency assert ( task != null ) Arbitrary code No effect on task == null An assertion that task might be null No Effect on inconsistency

36

Error Invariant Automaton

1: public TaskDialog(Tast task) ~: . . . . . . 6: txtDescription.setTask(task.getDescription()); ~: . . . . . . 16: if (notification) { . . . . . } ~: . . . . 27: chbRegular.setEnabled(task == null); ~: . . . . }

line 1 - 5 line 6 line 7 - 26 line 27 line 28 - end No Effect on inconsistency assert ( task != null ) Arbitrary code No effect on task == null An assertion that task might be null No Effect on inconsistency

37

Error Trace

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

38

Error Trace

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

Λ

task null Λ task null Λ

39

Error Invariant

An error invariant for a position ∈ [ ] in an error trace is a first order logical formula such that.

• The conjunction of the first order logical formulas for each statement

implies Ii.

• Ii and the conjunction of the remaining formulas is unsatisfiable.

40

ErrInv( )

In the previous work, the authors introduced a function ⊼ which given an error trace, computes: 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

Inductive error invariant

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

42

Inductive error invariant

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

43

Inductive error invariant

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

44

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

Algorithm

Now, after applying step 1 we got a single path π A. Step 2: Apply ErrInv( π A ) ErrInv(π A) = ErrInv( π ) = I0st(li1). . . . . . st(lik)Ik.

Algorithm

47

Now, after applying step 1 we got a single path π A. Step 2: Apply ErrInv( π A ) ErrInv(π A) = ErrInv( π ) = I0st(li1). . . . . . st(lik)Ik.

I2 I5 I3 I4 I1 I0

Algorithm

48

Now, after applying step 1 we got a single path π A. Step 2: Apply ErrInv( π A ) ErrInv(π A) = ErrInv( π ) = I0st(li1). . . . . . st(lik)Ik.

I2 I5 I3 I4 I1 I0 error invariants

Algorithm

49

Example:

assume(task !=null) assume(task =null)

Algorithm

50

Example:

assume(task !=null) assume(task =null) assume(task !=null) assume(task =null)

true task != null false

ErrInv()

Algorithm

Step 3: The locations covered with an inductive error invariant can be collapsed into a single location.

51

I0 I1 I5 I1 I4 I0 I0 I1 I4 I5

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

52

I0 I5 I2 I1

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

53

I0 I5 Apply the algo recursively to these non- atomic statements I2 I1

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

54

I0 I5 In case of this location Pre Post I2 I1

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

55

I0 I5 In case of the location with invariant I2 Inconsistent w.r.t pre and post Post I2 I1 Pre

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

56

I0 I5 In case of the location with invariant I2 I2 I1

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

57

I0 I5 In case of the location with invariant I2 pre post I2

recursively

I1

Algorithm

Step 4: For each remaining non-atomic statement, apply the algorithm recursively to all these smaller automata.

58

I0 I5 I2 I I1

Algorithm

1: public TaskDialog(Tast task) ~: . . . . . . 6: txtDescription.setTask(task.getDescription()); ~: . . . . . . 16: if (notification) { . . . . . } ~: . . . . 27: chbRegular.setEnabled(task == null); ~: . . . . }

59

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 0.008 seconds in

• ne of the experiments to 0.019 seconds.

60

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

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

References

63

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: http://dl.acm.org/citation.cfm?id=2491411 Title: Explaining Inconsistent Code, pages: 521 - 531 Bixie - FInd inconsistencies in Java code. http://martinschaef.github.io/bixie/ 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, 2013. Proceedings url: http://link.springer.com/book/10.1007/978-3-642-35873-9 Title: Flow-Sensitive Fault Localization, pages : 189 - 208 .