References [1] LEAP:The Lightweight Deterministic Multi-processor Replay of Concurrent Java Programs [2] CLAP:Recording Local Executions to Reproduce Concurrency Failures [3] Persuasive Prediction of Concurrency Access Anomlies [4] Maximal Sound Predictive Race Detection with Control Flow Abstraction [5] Maximal Casual Models for Sequentially Consistent Systems

1 Introduction Concurrent programs are plagued by a class of bugs called Heisenbugs, such as data races, order violations, deadlocks atomicity violations, and atomic-set serializability violations that are easy to hatch but difficult to detect and to fix.

1 Introduction Concurrent programs are plagued by a class of bugs called Heisenbugs, such as data races, order violations, deadlocks atomicity violations, and atomic-set serializability violations that are easy to hatch but difficult to detect and to fix. Concurrency bugs are notoriously difficult to test ,because of the non-determinism property of concurrent programs.

1 Introduction We have two techniques to deal with this problem.

1 Introduction We have two techniques to deal with this problem. One is the record and replay technique, it aims at fully reenacting the problematic execution of concurrent programs, thus giving the programmers both the context and the history information to dramatically expedite the process of bug fix.

1 Introduction We have two techniques to deal with this problem. One is the record and replay technique, it aims at fully reenacting the problematic execution of concurrent programs, thus giving the programmers both the context and the history information to dramatically expedite the process of bug fix. A crucial design factor of record and replay solutions is amount of data to be recorded and degree of faithfulness in replay

2 Record and Replay Dejavu is a global clock based approach.

2 Record and Replay Dejavu is a global clock based approach. Record a global order of critial events. Enforce the same global order in replay phase.

2 Record and Replay Dejavu is a global clock based approach. Record a global order of critial events. Enforce the same global order in replay phase. <t1,t2,t1,t2,t2,t1,t1>

2 Record and Replay LEAP is a local-order based deterministic replay.

2 Record and Replay LEAP is a local-order based deterministic replay. Observation: it is sufficient to record partial thread access information local to the individual shared variables.

2 Record and Replay LEAP is a local-order based deterministic replay. Observation: it is sufficient to record partial thread access information local to the individual shared variables. Record: x:<t1,t2,t1> y:<t2,t1,t2>

2 Record and Replay Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations

2 Record and Replay Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations LEAP record x:<t1,t2,t1>,y:<t2,t1,t2>,record 6 operations, and recording on different memory locations can be parallelized.

2 Record and Replay Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations LEAP record x:<t1,t2,t1>,y:<t2,t1,t2>,record 6 operations, and recording on different memory locations can be parallelized. So LEAP is more efficient than Dejavu.

2 Record and Replay CLAP is a record and replay techniques based on SMT slover. Main idea: do not record order but compute it.

2 Record and Replay CLAP is a record and replay techniques based on SMT slover. Main idea: do not record order but compute it. Record:log thread local execution paths at runtime. Compute schedule through sloving constraints.

2 Record and Replay CLAP is a record and replay techniques based on SMT slover. Main idea: do not record order but compute it. Record:log thread local execution paths at runtime. Compute schedule through sloving constraints.

2 Record and Replay SMT slovers: Popular SMT slovers - Z3,Yices,STP,MathSAT,CVC4,OpenSMT...

2 Record and Replay SMT slovers: Popular SMT slovers - Z3,Yices,STP,MathSAT,CVC4,OpenSMT... x1<x2 & x2<x3 & x3<x1 ??

2 Record and Replay SMT slovers: Popular SMT slovers - Z3,Yices,STP,MathSAT,CVC4,OpenSMT... x1<x2 & x2<x3 & x3<x1 ?? no solution!!

2 Record and Replay SMT slovers: Popular SMT slovers - Z3,Yices,STP,MathSAT,CVC4,OpenSMT... x1<x2 & x2<x3 & x3<x1 ?? no solution!! x1<x2 & x3<x4 & (x2<x3 | x1<x4) ??

2 Record and Replay SMT slovers: Popular SMT slovers - Z3,Yices,STP,MathSAT,CVC4,OpenSMT... x1<x2 & x2<x3 & x3<x1 ?? no solution!! x1<x2 & x3<x4 & (x2<x3 | x1<x4) ?? - [x1,x2,x3,x4]=[0,1,2,3]

2 Record and Replay Record: - T1;[1,2,3,4] T2:[5,6,7]

2 Record and Replay Record: - T1;[1,2,3,4] T2:[5,6,7] O: order variable for each shared data access S: symbolic value for each shared data read

2 Record and Replay Constraints: Path Constraints: - x3=Sx3,y6=Sy6,x3<0,y6==1

2 Record and Replay Constraints: Path Constraints: - x3=Sx3,y6=Sy6,x3<0,y6==1 Order Constraints: - O1<O2<O3 O5<O6<O7

2 Record and Replay Constraints: Path Constraints: - x3=Sx3,y6=Sy6,x3<0,y6==1 Order Constraints: - O1<O2<O3 O5<O6<O7 Read-Write Constrints: - Sx3= x1 & (O7<O1 | O7>O3)| x7 & (O1<O7<O3) - Sy6= y5 & (O2<O5 | O2>O6)| y2 & (O5<O2<O6)

2 Record and Replay Path Constraints: - x3=Sx3,y6=Sy6,x3<0,y6==1 Order Constraints: - O1<O2<O3 O5<O6<O7 Read-Write Constrints: - Sx3= x1 & (O7<O1 | O7>O3)| x7 & (O1<O7<O3) - Sy6= y5 & (O2<O5 | O2>O6)| y2 & (O5<O2<O6) Slover:O1=2 O2=3 O3=6 O5=1 O6=4 O7=5

2 Record and Replay Original Schedule: <1,5,2,6,7,3,4> -> ERROR Slover: <5,1,2,6,7,3,4> -> ERROR

3 Execution Model The Other technique is predictive trace analysis(PTA).

3 Execution Model The Other technique is predictive trace analysis(PTA). The PTA is a detection technique of concurrency bugs.

3 Execution Model The common pattern for all these methods is (1) The program is instrumented to trace the execution of programs

3 Execution Model The common pattern for all these methods is (1) The program is instrumented to trace the execution of programs (2) One execution trace is recorded

3 Execution Model The common pattern for all these methods is (1) The program is instrumented to trace the execution of programs (2) One execution trace is recorded (3) An abstraction of that trace, i.e., a model, is derived

3 Execution Model (4) The obtained model is used to predict (problematic) event patterns occurring in other possible executions abstracted by it.

3 Execution Model Many PTA techniques are based on an execution model of concurrent programs.

3 Execution Model Many PTA techniques are based on an execution model of concurrent programs. We wish execution model contains feasible traces as many as possible

3 Execution Model Many PTA techniques are based on an execution model of concurrent programs. We wish execution model contains feasible traces as many as possible Two properties of a good Execution Model - Soundness, Maximality

3 Execution Model Some this kind models: The conventional happens-before causality: if two conflicting accesses to an object are not causally ordered, then a data-race is reported.

3 Execution Model The model used by Pecan: a hybrid constraint model that combines the lockset condition and the happens-before relation.

3 Execution Model The model used by Pecan: a hybrid constraint model that combines the lockset condition and the happens-before relation. The Partial Order Relation (POR) ei →ej holds for Program order, Fork-join order, Wait-notify order

3 Execution Model The model used by Pecan: a hybrid constraint model that combines the lockset condition and the happens-before relation. The Partial Order Relation (POR) ei →ej holds for Program order, Fork-join order, Wait-notify order The Temporal Order Relation(TOR) ei-->ej

3 Execution Model Based on this model, Pecan get a Partial and Temporal Order Graph(PTG), and then search patterns in this Graph to detect concurrent bugs.

3 Execution Model Example:

3 Execution Model Example: We get a trace <1,5,2,3,6,7>

3 Execution Model e1: Write(1,1,x) e5: Write(2,2,y) e2: Write(3,1,y) e6: Read(5,2,y) e3: Read(4,1,x) e7: Write(6,2,x)

3 Execution Model e1: Write(1,1,x) e5: Write(2,2,y) e2: Write(3,1,y) e6: Read(5,2,y) e3: Read(4,1,x) e7: Write(6,2,x) POR: e1->e2->e3 e5->e6->e7 TOR: e1-->e3-->e7 (for x) e5-->e2-->e6 (for y)

3 Execution Model PTG:

3 Execution Model PTG: We search patterns in this PTG and get for data race: (3,7) (5,2) (2,6) (1,7)

3 Execution Model But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race.

3 Execution Model But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race. But Pecan can prune this false warning during re-execution phase

3 Execution Model But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race. But Pecan can prune this false warning during re-execution phase So the hybrid constraint model is not sound because of it is a conservative approxmation. So Pecan may report false positives during the pattern search.

3 Execution Model A race between lines (3,10).

3 Execution Model A race between lines (3,10). An execution trace <1,2,3,4,5,6,7,8,9,10,11, 12,13,14,15,16,17>

3 Execution Model CP relax the HB edges between critical sections that have no conflicting accesses.

3 Execution Model CP relax the HB edges between critical sections that have no conflicting accesses. For the two lock regions all accesses to y.CP cannot detect this race

3 Execution Model PECAN is able to detect this race.

3 Execution Model PECAN is able to detect this race. But if we switch lines 1 and 2, (3,10) is no longer a race PECAN will still report it.

3 Execution Model We get a trace <1,2,3,4> (1,4) is a race in , but not in .

3 Execution Model We get a trace <1,2,3,4> (1,4) is a race in , but not in . A sound technique conservatively creates a HB edge from line 2 to line 3 and misses the race in case .

3 Execution Model With the control flow information, line 4 is not control-dependent on line 3 in case .

3 Execution Model With the control flow information, line 4 is not control-dependent on line 3 in case . we can safely drop the HB edge from line 2 to line 3, which enables detecting the race (1,4).

3 Execution Model So,we can detect the race (3,10) by dropping the HB edge from line 4 to line 8

3 Execution Model branch(t): jump to a new operation. We conservatively assume that the choice of branch(t) depends on all the previous read(t, x, v) operations executed by the same thread.

3 Execution Model

3 Execution Model

3 Execution Model Consistency of trace t means precisely the following: Read Consisitency, Lock Mutual Exclusion, Must Happen-Before

3 Execution Model Consistency of trace t means precisely the following: Read Consisitency, Lock Mutual Exclusion, Must Happen-Before An consistent interleaving of t is a trace t' such that t|thread=t'|thead for each thread.

3 Execution Model The Common Execution Model for a trace t', iff t|thread=t'|thead for all thread, and t' satisfies the consistency property, t' feasible(P).

3 Execution Model Consistent Interleavings of the original trace such as, <1,6,2,3,4,5,7,8,9...> <1,2,6,3,4,5,7,8,9...> are all belong to feasible(P)

3 Execution Model Consistent Interleavings of the original trace such as, <1,6,2,3,4,5,7,8,9...> <1,2,6,3,4,5,7,8,9...> are all belong to feasible(P) <1,6,7,8,9,2,3,4,5...>is not in feasible(P) because t|thread≠t'|thead

3 Execution Model The Weaker Execution Model Formally, if t1e1, t2 feasible(P) and t1|thread(e1)= t2|thread(e1) then (1) if t2e1 is consistent then t2e1 feasible(P) (2) if op(e1) =read and there exists some event e2 with e2[data(e1)/data] = e1,and t2e2 consistent, then t2e2 feasible(P).

3 Execution Model The Weaker Execution Model Formally, if t1e1, t2 feasible(P) and t1|thread(e1)= t2|thread(e1) then (1) if t2e1 is consistent then t2e1 feasible(P) (2) if op(e1) =read and there exists some event e2 with e2[data(e1)/data] = e1,and t2e2 consistent, then t2e2 feasible(P). So <1,6,7,8',....> is in feasible(P), but <1,6,7,8',9...>is not. 8' is read(t2,y,0)

3 Execution Model

3 Execution Model Proof: t1:<1,2,3,4,5,6,7> e1:8 t2:<1,6,7>, all feasible(P) thread(e1)=th t1|th= t2|th=<6,7> but <1,6,7,8> is not consistent <1,6,7,8> feasible(P) 8'=8[data(8)/0] and <1,6,7,8'>is consistent <1,6,7,8'> feasible(P)

3 Execution Model But <1,6,7,8',9> is not in feasible<P>

3 Execution Model But <1,6,7,8',9> is not in feasible<P> Because <1,6,7,8>|thread(9)≠<1,6,7,8'>|thread(9),9 is not a read event and <1,6,7,8',9>is not consistent because it can not satisfy Read Consistency.

3 Execution Model The RVPredict Execution Model Suppose that t1e1, t2 feasible(P) , that thread(e1) = th and that t1|th t2|th. called data-abstract equivalence, iff they are equal except for the data values in read and write events.

3 Execution Model The RVPredict Execution Model Suppose that t1e1, t2 feasible(P) , that thread(e1) = th and that t1|th t2|th. called data-abstract equivalence, iff they are equal except for the data values in read and write events. Branch. If op(e1) = branch and t1|th,read = t2|th,read then t2e1 feasible(P).

3 Execution Model Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent, then t2e2 feasible(p)

3 Execution Model Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent, then t2e2 feasible(p) Write. If op(e1) = write then there is a v such that t2e1[v/data] feasible(P), moreover,if t1|th,read =t2|th,read then v = data(e1).

3 Execution Model Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent, then t2e2 feasible(p) Write. If op(e1) = write then there is a v such that t2e1[v/data] feasible(P), moreover,if t1|th,read =t2|th,read then v = data(e1). Other. If op(e1) {branch,read,write} and t2e1 is consistent, then t2e1 feasible(P).

3 Execution Model Then <1,6,7,8',9...> is in feasible(P)

3 Execution Model Then <1,6,7,8',9...> is in feasible(P) Proof:thread(9)=th <1,6,7,8>|th <1,6,7,8'>|th and op(9)=release; and <1,6,7,8',9> is consistent, so <1,6,7,8',9> feasible(P)

3 Execution Model The Sound and Maximal model contains branch events, so there are more feasible trace in it. Any PTAs which base on this execution model have a greater detection capability than other PTAs which base on other execution models.

3 Execution Model Because of some conservative assumption such as branch and write events depend upon all the reads by the same thread. We think this limitation is too strong, as I think, branch and write events just can depend upon some read events by the same thread, but not all read events. This strategy may give execution model a larger coverage than other execution model.