A True Positives Theorem for a Static Race Detector Presentation by - PowerPoint PPT Presentation

A True Positives Theorem for a Static Race Detector Presentation by Julia Belyakova and Artem Pelenitsyn For CS 7580 (instructor: Jan Vitek), 10/30/2019 A subset of slides is taken from Ilya Sergey’s web page

Static Analyses 
 for Program Validation 7

The Essence of Static Analysis “abstraction” α C e p program 
 property 
 execution of interest 8

α e 1 p α e 2 9

Static Analysis p 1 e 1 p 2 e 2 concreteSem ( c ) = e 3 e 6 e 4 p 3 e 5 p 4 10

Static Analysis p 1 } “has bugs” e 1 p 2 e 2 } concreteSem ( c ) = e 3 e 6 e 4 p 3 e 5 “correct” p 4 11

Verifier 
 or a 
 Bug Detector? 12

Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 true negative p 4 13

Sound Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 true negative p 4 14

Sound Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 true negative p 4 abstract over-approximation < 15

Sound Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 true negative p 4 abstract over-approximation < 16

Sound Program Verifier true positive p 1 Developer : e 1 Go away, that never happens! false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 true positive p 4 if (n == VERY_UNLIKELY_VALUE) { bug.explode(); } else { // do nothing } 17

Unsound Program “Verifier” true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 if (n == VERY_UNLIKELY_VALUE) { bug.explode(); } else { // do nothing } 18

“Sound” Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 6 e 4 true negative p 3 e 5 false negative p 4 19

“Sound” Program Verifier true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 concrete under-approximation abstract over-approximation < 20

Sound Static Verifiers • False negatives (bugs missed) are bad • False positives (non-bugs reported) are okay • Constructed as over-approximation ( of under-approximation ) • Soundness Theorem : 
 Under certain assumptions about the programs, the analyser has no false negatives . 21

p 1 } “has bugs” e 1 p 2 e 2 } e 3 e 6 e 4 p 3 e 5 “correct” p 4 22

Static Bug Finder true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 23

Unsound Static Bug Finder true positive p 1 e 1 false positive p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 24

Sound (but imprecise) Static Bug Finder true positive p 1 e 1 false negative p 2 e 2 e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 abstract under-approximation < 25

Loss of Precision in Static Bug Finders if (n != VERY_UNLIKELY_VALUE) { e 2 // bug happens here } else { e 3 // normal execution } Idea: over-approximate in concrete semantics! 26

Sound (but Imprecise) Static Bug Finder true positive p 1 e 1 false negative p 2 e 2 Let’s merge these executions into Let’s consider these two equivalent! one that subsumes both! e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 27

if (*) { // bug happens here } else { true positive p 1 // normal execution } e 1 false negative true positive p 2 p 2 e 2 e 23 overApproxConcreteSem (c) = 1. e 3 e 6 e 4 true negative p 3 e 5 false negative p 4 28

Sound Static Bug Finder if (*) { // bug happens here } else { true positive p 1 // normal execution } e 1 true positive p 2 e 23 overApproxConcreteSem (c) = 1. e 6 e 4 true negative p 3 e 5 false negative p 4 concrete over-approximation abstract under-approximation < 29

Towards Sound Static Bug Finders (this work) • False negatives (bugs missed) are okay • False positives (non-bugs reported) are bad • Constructed as under-approximation of over-approximation • Soundness (True Positives) Theorem : 
 Under certain assumptions about the programs, the analyser has no false positives . 30

A True Positives Theorem 
 for a Static Race Detector Nikos Gorogiannis Peter O’Hearn Ilya Sergey

Key Messages Unsound (and incomplete) static analyses can be principled , satisfying meaningful theorems 
 that help to understand their behaviour and guide their design One can have an unsound but effective static analysis, 
 which has significant industrial impact, 
 and which is supported by a meaningful theorem . 2

Context 1. We had a demonstrably-effective industrial analysis: 
 RacerD (OOPSLA'18); >3k fixes in Facebook Java 2. No soundness theorem 3. Architecture: compositional abstract interpreter 4. No heuristic alarm filtering Just ad hoc? Our reaction: 
 Semantics/theory should understand/explain, not lecture. 5

Case Study: RacerDX • A provably TP-Sound version of Facebook’s RacerD concurrency analyser 
 (Blackshear et al., OOPSLA’18) • Buggy executions: data races in lock-based concurrent programs • Syntactic assumptions : 
 Java programs with well-scoped locking ( synchronised ), no recursion, reflection, dynamic class loading; global variables are ignored. • Concrete over-approximation : 
 Loops and conditionals are non-deterministic. 32

Formal Result RacerDX enjoys the True Positives Theorem wrt . Data Race Detection (Details in the paper) 38

For an Idealized Language Static Analysis with True Positives Theorem* Goal : to build a static analysis s.t. if the analysis reports a bug , it is a true bug 1

True bug can be exhibited The race reported There exists by the analysis an execution of P for program P that exhibits is a true race the race 2

Ingredients program ● execution of the formalism ● race ● analysis ● For an Idealized Language proof ● 3

Ingredients of a data race lock () println(b.f) unlock () path Racy Program: b = new Bloop() u = new Burble() b.f := 42 u.meps(b) || u.reps(b) parallel composition 4

Concurrent program syntax 5

State ● (command, stack, heap, locks) Single-threaded program C : Trace (list of states) ● concrete semantics Concrete semantics ● (set of traces) 6

Concrete semantics of commands 7

Concrete semantics of commands stack heap command # of locks empty trace top stack frame value of var x location pointed by π given stack s & heap h 8

Concrete semantics of compound statements (1) run C , get all its traces (2) take the last state of each trace (4) glue traces of C and c together (3) run c from the last state, get its traces 9

Concrete trace example no lock Stack s0 Initial state: memory location 〈 skip, s0, h0, 0 〉 a p1 Heap h0 [ 〈 lock (), s0, h0, 1 〉 , lock () (p1, f) p2 a.f := 5 〈 a.f:=5, s0, h1, 1 〉 , (p2, _) 666 unlock () 〈 unlock (), s0, h1, 0 〉 ] Heap h1 (p1, f) p2 program execution trace (p2, _) 5 10

State ● Two-threaded c ။ ε or ε ။ c program C 1 ။ C 2 : concrete semantics Trace ● Concrete semantics ● 11

2-threaded program interleaves single traces (2) interleave all individual traces (full and partial) (1) run components individually 12

Concurrent traces example interleave lock () lock () (taking care of locks) x := 5 x := 777 unlock () unlock () print(1) print(2) lock () ။ ε lock () lock () lock () x := 5 ။ ε x := 5 y := 777 x := 5 unlock () ။ ε unlock () unlock () lock () print(1) ။ ε lock () print(2) … ε ။ lock () y := 777 lock () ε ။ y := 777 … unlock () ε ။ unlock () print(1) ε ။ print(2) 13

Data race means concurrent access to location 14

Data race means concurrent access to location print(1) ။ ε print(1) ။ ε ε ။ print(2) ε ။ print(2) … lock () ။ ε lock () ။ ε a.f := 5 ။ ε ε ။ y := a.f no lock! print(1) print(1) ။ ε lock () print(2) ε ။ print(2) a.f := 5 y := a.f lock () ။ ε unlock () ε ။ y := a.f a.f := 5 ။ ε concurrent Write ။ Read to the same location 15

Can we identify a data race without building the traces? 16

Abstract Semantics Abstract State ● tracks accesses (wobblies, locks, path accesses) to memory locations Abstraction of a set of ● helps identify concrete single -threaded traces true races = 17

Wobblies can evade data races (produce false positives) same path b.f refers to different locations 18

Abstraction keeps track of accesses and wobblies 𝜐 without heap, stack, locks substitution (needed for method calls) (3) mark x & π as wobbly (2) remember access to π (1) abstract the beginning of the trace abstract set of traces using exec discard substitution 19

Why reading is wobbly? same path a.f.n a p1 refers to different locations, so there is no race lock () x := a a.f.n := 5 // a.f.n x.f := new … unlock () y := a.f.n (p1, f) p2 (p2, n) p3 (p1, f) p4 (p2, n) p3 (p4, n) p5 20

Abstract access captures concrete access If a path access is recorded in the abstract state, there is a concrete trace exhibiting the access 21