without Regret Barbara Jobstmann EPFL and Jasper DA CNRS, Verimag - PowerPoint PPT Presentation

Program Repair without Regret Barbara Jobstmann EPFL and Jasper DA CNRS, Verimag Joint Work with Christian von Essen UJF, Verimag Google Zurich 4th April 2014 B. Jobstmann 1

Agenda • Introduction – Motivation – Program Repair, related choices, our choices – Example • Our Repair approach – Exact and relaxed repair problem – Reduction to classical synthesis – General and efficient algorithm – Implementation and results • Conclusion and future work 4th April 2014 B. Jobstmann 2

Motivation • Debugging can be tedious – Find the bug – Locate it – Fix it 4th April 2014 B. Jobstmann 3

Motivation • Debugging can be tedious – Find the bug: model checking – Locate it: automatically analyze/modify/explain CEX/witness – Fix it: automatically repair 4th April 2014 B. Jobstmann 4

Automatic Repair • Given faulty program + (explicit/implicit) specification • Search for modification s. t. modified program is – “correct” and – “similar” to the original program • Key choices in an repair approach: – Type of programs and specifications – Which modification do you allow? – How to you find and check corrections? – What do you mean by “similar”? 4th April 2014 B. Jobstmann 5

Key choices 1. Type of programs and specifications – Data or control-oriented – Specific properties (e.g., deadlock), general properties (e.g., given in a logic), explicit/implicit 2. Which modification do you allow? – Syntactic modifications, e.g., based on expression language, genetic algorithms, … 3. How to you find and check corrections? – “Smart” enumeration and verification – “Synthesize” (combine search and verification) 4. What do you mean by “similar”? – Focus on syntactic similarity (e.g., edit distance, …) 4th April 2014 B. Jobstmann 6

Our Choices [following CAV’05] 1. Type of programs and specifications – Reactive finite-state programs (Mealy machines) – General properties specified using LTL) 2. Which modification do you allow? – Theory: functions over state/input variables – Implementation: expression language 3. How to you find and check corrections? – Combine search and verification using game theory 4. What do you mean by “similar”? – Syntactic similarity (given by expression language) – Semantic similarity (NEW in this work) 4th April 2014 B. Jobstmann 7

Choice 1: Programs and specifications State variables: mainLight = Red; sideLight = Red; mainLight in {Red, Yellow, Green} always @ ( posedge clock) sideLight in {Red, Yellow, Green} begin Input variables: case (mainLight) mainSensor in {True, False} Red: if (mainSensor) mainLight = Yellow; sideSensor in {True, False} Yellow: mainLight = Green; Behavior represented as (infinite) sequence of Green: mainLight = Red; evaluations of state and input variables: w ∈ 𝐹(𝑊) 𝜕 endcase // case (mainLight) case (sideLight) Program represented as set of behaviors: 𝑀 𝑄 Step 1 2 3 4 … Red: if (sideSensor) mL Red Yellow Green Red … sideLight = Yellow; sL Red Red Red Yellow … Yellow: sideLight = Green; mS True True False … … Green: sideLight = Red; endcase // case (sideLight) sS False False True … … end 4th April 2014 8

Choice 1: Programs and specifications State variables: mainLight = Red; sideLight = Red; mainLight in {Red, Yellow, Green} always @ ( posedge clock) sideLight in {Red, Yellow, Green} begin Input variables: case (mainLight) mainSensor in {True, False} Red: if (mainSensor) mainLight = Yellow; sideSensor in {True, False} Yellow: mainLight = Green; Behavior represented as (infinite) sequence of Green: mainLight = Red; evaluations of state and input variables: w ∈ 𝐹(𝑊) 𝜕 endcase // case (mainLight) case (sideLight) Program represented as set of behaviors: 𝑀 𝑄 Red: if (sideSensor) sideLight = Yellow; Specification represented as set of behaviors: 𝑀(φ ) Yellow: sideLight = Green; Green: sideLight = Red; Specification: endcase // case (sideLight) never (mainLight == Green end and sideLight == Green) 4th April 2014 9

Choice 2: Modifications State variables: mainLight = Red; sideLight = Red; mainLight in {Red, Yellow, Green} always @ ( posedge clock) sideLight in {Red, Yellow, Green} begin Input variables: case (mainLight) mainSensor in {True, False} Red: if (mainSensor) ??? mainLight = Yellow; sideSensor in {True, False} Yellow: mainLight = Green; Behavior represented as (infinite) sequence of Green: mainLight = Red; evaluations of state and input variables: w ∈ 𝐹(𝑊) 𝜕 endcase // case (mainLight) case (sideLight) Program represented as set of behaviors: 𝑀 𝑄 Red: if (sideSensor) sideLight = Yellow; Specification represented as set of behaviors: 𝑀(φ ) Yellow: sideLight = Green; Green: sideLight = Red; Allowed modifications : endcase // case (sideLight) function over state and input variables end Specification: never (mainLight == Green and sideLight == Green) 4th April 2014 10

Choice 3: Repair Search using Games State variables: mainLight = Red; sideLight = Red; mainLight in {Red, Yellow, Green} always @ ( posedge clock) sideLight in {Red, Yellow, Green} begin Input variables: Input variables: case (mainLight) mainSensor in {True, False} mainSensor in {True, False} Red: if (mainSensor) ??? mainLight = Yellow; sideSensor in {True, False} sideSensor in {True, False} Yellow: mainLight = Green; Behavior represented as (infinite) sequence of Green: mainLight = Red; evaluations of state and input variables: w ∈ 𝐹(𝑊) 𝜕 endcase // case (mainLight) case (sideLight) Program represented as set of behaviors: 𝑀 𝑄 Red: if (sideSensor) sideLight = Yellow; Specification represented as set of behaviors: 𝑀(φ ) Yellow: sideLight = Green; Green: sideLight = Red; Allowed modifications : endcase // case (sideLight) function over state and input variables end Specification: Winning objective: repaired program is correct, i.e., never (mainLight == Green 𝑀 𝑄 ′ ⊆ 𝑀(φ ) and sideLight == Green) 4th April 2014 11

Choice 4: Similarity State variables: mainLight = Red; sideLight = Red; mainLight in {Red, Yellow, Green} always @ ( posedge clock) sideLight in {Red, Yellow, Green} begin Input variables: Input variables: case (mainLight) mainSensor in {True, False} mainSensor in {True, False} Red: if (mainSensor) ??? mainLight = Yellow; sideSensor in {True, False} sideSensor in {True, False} Yellow: mainLight = Green; Behavior represented as (infinite) sequence of Green: mainLight = Red; evaluations of state and input variables: w ∈ 𝐹(𝑊) 𝜕 endcase // case (mainLight) case (sideLight) Program represented as set of behaviors: 𝑀 𝑄 Red: if (sideSensor) sideLight = Yellow; Specification represented as set of behaviors: 𝑀(φ ) Yellow: sideLight = Green; Green: sideLight = Red; Allowed modifications : endcase // case (sideLight) “simple” function over state and input variables end Specification: Winning objective: repaired program is correct, i.e., never (mainLight == Green 𝑀 𝑄 ′ ⊆ 𝑀(φ ) and sideLight == Green) 4th April 2014 12

Simple Repair mainLight = Red;  No car crash: correct repair sideLight = Red;  Main street blocked always @ ( posedge clock) begin What went wrong? case (mainLight) Lost intended behavior; changed (mainSensor & !(sideLight == Red & sideSensor)) Red: if (mainSensor) false behaviors unnecessarily mainLight = Yellow; Yellow: mainLight = Green; Idea: semantic similarity Green: mainLight = Red; • endcase // case (mainLight) Keep correct behaviors • case (sideLight) Modifications must not Red: if (sideSensor) effect correct behaviors sideLight = Yellow; [Angelic debugging, Chandra et al.] Yellow: sideLight = Green; Extend objective: repair keeps correct behaviors Green: sideLight = Red; 𝑀 𝑄 ∩ 𝑀 φ ⊆ 𝑀 𝑄 ′ endcase // case (sideLight) end Specification: Winning objective: repaired program is correct, i.e., never (mainLight == Green 𝑀 𝑄 ′ ⊆ 𝑀(φ ) and sideLight == Green) 4th April 2014

Agenda • Introduction – Motivation – Program Repair, related choices, our choices – Example • Our Repair approach – Exact and relaxed repair problem – Reduction to classical synthesis – General and efficient algorithm – Implementation and results • Conclusion and future work 4th April 2014 B. Jobstmann 14

Exact Repair Problem Program 𝑄′ is an “exact repair” of program 𝑄 for specification φ if (i) all correct behaviors of 𝑄 w.r.t. φ are part of 𝑄′ , (ii) all behaviors of 𝑄 ’ are correct w.r.t. φ , i.e., 𝑀 𝑄 ∩ 𝑀 φ ⊆ 𝑀 𝑄 ′ ⊆ 𝑀(φ ) Ideal but sometimes too restrictive: • exact repair might not exists • exact repair might not be required P’ P φ φ = φ 𝑏 → φ 𝑕 Behaviors that do not satisfy φ 𝑏 are correct but might not need to be preserved 4th April 2014 B. Jobstmann 15

Relaxed Repair Problem Program 𝑄′ is an “relaxed repair” of program 𝑄 for specifications φ and 𝜔 if (i) all correct behaviors of 𝑄 w.r.t. 𝜔 are part of 𝑄′ , (ii) all behaviors of 𝑄 ’ are correct w.r.t. φ , i.e., 𝑀 𝑄 ∩ 𝑀 𝜔 ⊆ 𝑀 𝑄 ′ ⊆ 𝑀(φ ) P P’ φ ψ 4th April 2014 B. Jobstmann 16

Some choices for 𝜔 • Exact repair 𝜔 = φ • Assume-Guarantee: if φ = φ 𝑏 → φ 𝑕 , then 𝜔 = φ 𝑏 ∧ φ 𝑕 • Classical repair 𝜔 = ∅ 4th April 2014 B. Jobstmann 17