1 RELAY: Static Race Detection on Millions of Lines of Code Jan Voung, Ranjit Jhala, and Sorin Lerner UC San Diego speaker.

Slides:



Advertisements
Similar presentations
Dataflow Analysis for Datarace-Free Programs (ESOP 11) Arnab De Joint work with Deepak DSouza and Rupesh Nasre Indian Institute of Science, Bangalore.
Advertisements

Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Pallavi Joshi  Chang-Seo Park  Koushik Sen  Mayur Naik ‡  Par Lab, EECS, UC Berkeley‡
Effective Static Deadlock Detection
1 Chao Wang, Yu Yang*, Aarti Gupta, and Ganesh Gopalakrishnan* NEC Laboratories America, Princeton, NJ * University of Utah, Salt Lake City, UT Dynamic.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Conditional Must Not Aliasing for Static Race Detection Mayur Naik Alex Aiken Stanford University.
Goldilocks: Efficiently Computing the Happens-Before Relation Using Locksets Tayfun Elmas 1, Shaz Qadeer 2, Serdar Tasiran 1 1 Koç University, İstanbul,
1 1 Regression Verification for Multi-Threaded Programs Sagar Chaki, SEI-Pittsburgh Arie Gurfinkel, SEI-Pittsburgh Ofer Strichman, Technion-Haifa Originally.
A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Koushik Sen CS 265.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Eraser: A Dynamic Data Race Detector for Multithreaded Programs STEFAN SAVAGE, MICHAEL BURROWS, GREG NELSON, PATRICK SOBALVARRO and THOMAS ANDERSON.
/ PSWLAB RacerX: Effective, Static Detection of Race Conditions and Deadlocks by Dawson Engler & Ken Ashcraft (published in SOSP03) Hong,Shin.
Static Data Race detection for Concurrent Programs with Asynchronous Calls Presenter: M. Amin Alipour Software Design Laboratory
Atomicity in Multi-Threaded Programs Prachi Tiwari University of California, Santa Cruz CMPS 203 Programming Languages, Fall 2004.
CS 263 Course Project1 Survey: Type Systems for Race Detection and Atomicity Feng Zhou, 12/3/2003.
Big Picture Lab 4 Operating Systems Csaba Andras Moritz.
S. Narayanasamy, Z. Wang, J. Tigani, A. Edwards, B. Calder UCSD and Microsoft PLDI 2007.
TaintCheck and LockSet LBA Reading Group Presentation by Shimin Chen.
CS533 Concepts of Operating Systems Class 3 Data Races and the Case Against Threads.
Scalable Error Detection using Boolean Satisfiability 1 Yichen Xie and Alex Aiken Stanford University.
Next Section: Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis (Wilson & Lam) –Unification.
Ownership Types for Safe Programming: Preventing Data Races and Deadlocks Chandrasekhar Boyapati Robert Lee Martin Rinard Laboratory for Computer Science.
Mayur Naik Alex Aiken John Whaley Stanford University Effective Static Race Detection for Java.
Programming Language Semantics Java Threads and Locks Informal Introduction The Java Specification Language Chapter 17.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Synchronization in Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
CS533 Concepts of Operating Systems Class 3 Monitors.
RADAR: Dataflow Analysis for Concurrent Programs using Datarace Detection Ravi Chugh, Jan Voung, Ranjit Jhala, Sorin Lerner {rchugh, jvoung, jhala, lerner}
Chapter 6: Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Principles Module 6: Synchronization 6.1 Background 6.2 The Critical-Section.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
/ PSWLAB Eraser: A Dynamic Data Race Detector for Multithreaded Programs By Stefan Savage et al 5 th Mar 2008 presented by Hong,Shin Eraser:
DETECTION OF POTENTIAL DEADLOCKS AND DATARACES ROZA GHAMARI Bogazici UniversityMarch 2009.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Introduction Overview Static analysis Memory analysis Kernel integrity checking Implementation and evaluation Limitations and future work Conclusions.
A Survey of Dynamic Techniques for Detecting Device Driver Errors Olatunji Ruwase LBA Reading Group 18 th May 2010.
Accelerating Precise Race Detection Using Commercially-Available Hardware Transactional Memory Support Serdar Tasiran Koc University, Istanbul, Turkey.
- 1 - Dongyoon Lee, Peter Chen, Jason Flinn, Satish Narayanasamy University of Michigan, Ann Arbor Chimera: Hybrid Program Analysis for Determinism * Chimera.
1 MT258 Computer Programming and Problem Solving Unit 7.
1 Effective Static Race Detection for Java Mayur, Alex, CS Department Stanford University Presented by Roy Ganor 14/2/08 Point-To Analysis Seminar.
Eraser: A Dynamic Data Race Detector for Multithreaded Programs STEFAN SAVAGE, MICHAEL BURROWS, GREG NELSON, PATRICK SOBALVARRO, and THOMAS ANDERSON Ethan.
50.530: Software Engineering Sun Jun SUTD. Week 8: Race Detection.
DoubleChecker: Efficient Sound and Precise Atomicity Checking Swarnendu Biswas, Jipeng Huang, Aritra Sengupta, and Michael D. Bond The Ohio State University.
Colorama: Architectural Support for Data-Centric Synchronization Luis Ceze, Pablo Montesinos, Christoph von Praun, and Josep Torrellas, HPCA 2007 Shimin.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
Dataflow Analysis for Concurrent Programs using Datarace Detection Ravi Chugh, Jan W. Voung, Ranjit Jhala, Sorin Lerner LBA Reading Group Michelle Goodstein.
Detecting and Eliminating Potential Violation of Sequential Consistency for concurrent C/C++ program Duan Yuelu, Feng Xiaobing, Pen-chung Yew.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
Effective Static Deadlock Detection Mayur Naik* Chang-Seo Park +, Koushik Sen +, David Gay* *Intel Research, Berkeley + UC Berkeley.
Effective Static Deadlock Detection Mayur Naik (Intel Research) Chang-Seo Park and Koushik Sen (UC Berkeley) David Gay (Intel Research)
Pointer and Escape Analysis for Multithreaded Programs Alexandru Salcianu Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology.
Eraser: A dynamic Data Race Detector for Multithreaded Programs Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, Thomas Anderson Presenter:
Unit 4: Processes, Threads & Deadlocks June 2012 Kaplan University 1.
Testing Concurrent Programs Sri Teja Basava Arpit Sud CSCI 5535: Fundamentals of Programming Languages University of Colorado at Boulder Spring 2010.
Where Testing Fails …. Problem Areas Stack Overflow Race Conditions Deadlock Timing Reentrancy.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Big Picture Lab 4 Operating Systems C Andras Moritz
FastTrack: Efficient and Precise Dynamic Race Detection [FlFr09] Cormac Flanagan and Stephen N. Freund GNU OS Lab. 23-Jun-16 Ok-kyoon Ha.
1 Active Random Testing of Parallel Programs Koushik Sen University of California, Berkeley.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Detecting Data Races in Multi-Threaded Programs
CSE 120 Principles of Operating
Effective Data-Race Detection for the Kernel
Reference-Driven Performance Anomaly Identification
Chapter 6: Synchronization Tools
50.530: Software Engineering
Eraser: A dynamic data race detector for multithreaded programs
Presentation transcript:

1 RELAY: Static Race Detection on Millions of Lines of Code Jan Voung, Ranjit Jhala, and Sorin Lerner UC San Diego speaker

2 Definition of data race  It is an event  between 2 threads, where there are  unordered accesses to the same memory location  and at least one of the accesses is a write … temp = g; … g = V; … thread 1 thread 2

3 Bugs from races  Example bug:  incorrect resource bounds … temp = size; … …; free(); size = size - n; … thread 1 thread 2

4 RELAY against data races  RELAY finds data races  RELAY is a static tool:  analyzes the program before it runs  RELAY is scalable:  analyzed the Linux kernel (4.5 million LOC)  in 5 hours on 32 cpus  Found 53 races in a sample of 149 warnings

5  Introduction  Computing locksets & recording accesses  Relative locksets  Guarded accesses  Experiments with Linux  Categorizing warnings: false positives  Filters targeting categories Outline

6 locks held Checking with Locksets lock(l); temp = g; unlock(l); … read(g); lock(l); g = 0; … thread 1 thread 2  Locks are a mechanism for mutual exclusion  Only one thread holds a particular lock at a time.  No race if the same lock must have been acquired for each of two different shared accesses locks held ll common lll

7 A more realistic (but simple) example read/write with lock write without lock work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } read_stats(x) { if (x->f1++ < 10) { unlock(x->lock); x->stats =...; } else unlock(x->lock); } No race Race

8 Key components of RELAY work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } read_stats(x) { if (x->f1++ < 10) { unlock(x->lock); x->stats =...; } else unlock(x->lock); } GOAL: scalability KEY: modularity work ( ) { … } read_stats ( ) {…} read_stats work

9 L+ = {}, L- = {} Key components of RELAY work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } read_stats(x) { if (x->f1++ < 10) { unlock(x->lock); x->stats =...; } else unlock(x->lock); } 1) Relative locksets: locks acq./rel. in function – caller handles locks before 2) Guarded accesses: pair accesses with relative locksets to catch races L+ = {}, L- = {x->lock} L+: MUST have been acq. L-: MAY have been rel. L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {x->lock} 3) Summaries 4) Symbolic execution: what is the “same” memory location? Normalize to globals and formals.

10 How RELAY runs read_stats(x) { if (x->f1++ < 10) { unlock(x->lock); x->stats =...; } else unlock(x->lock); } L+ = {}, L- = {} L+ = {}, L- = {x->lock} x->stats: L+ = {}, L- = {x->lock} x->f1: L+ = {}, L- = {} L+ = {}, L- = {x->lock} summary: 1) Assume symbolic execution ran. 2) Compute relative locksets 3) Compute guarded accesses x->stats: L+ = {}, L- = {x->lock} x->f1: L+ = {}, L- = {}

11 x->stats: L+ = {}, L- = {x->lock} How RELAY runs read_stats(x) x->stats: L+ = {}, L- = {x->lock} x->f1: L+ = {}, L- = {} L+ = {}, L- = {x->lock} summary: x->f1: L+ = {}, L- = {} L+ = {}, L- = {x->lock} summary:

12 x->stats: L+ = {}, L- = {x->lock} Applying summaries work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } read_stats(x) L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {} x->f1: L+ = {}, L- = {} L+ = {}, L- = {x->lock} summary: L+ = {}, L- = {d->priv->lock} summary: BEFORE DIFFERENCE AFTER

13 Applying summaries work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } read_stats(x) { L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {} L+ = {}, L- = {d->priv->lock} d->priv->stats: L+ = {}, L- = {d->priv->lock} d->priv->f1: L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {d->priv->lock} d->priv: L+ = {}, L- = {} summary: x->stats: L+ = {}, L- = {x->lock} x->f1: L+ = {}, L- = {} L+ = {}, L- = {x->lock} summary: L+ = {d->priv->lock}, L- = {} d->priv->f1: L+ = {d->priv->lock}, L- = {} BEFORE DIFFERENCE AFTER

14 Checking for Races d->priv->stats: L+ = {}, L- = {d->priv->lock} d->priv->f1: L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {d->priv->lock} d->priv: L+ = {}, L- = {} summary: work (void *d) { o = d->priv; lock(o->lock); read_stats(o); } L+ = {d->priv->lock}, L- = {} L+ = {}, L- = {} L+ = {}, L- = {d->priv->lock} L+ = {d->priv->lock}, L- = {} work (void *d) d->priv->stats: L+ = {}, L- = {d->priv->lock} d->priv->f1: L+ = {d->priv->lock}, L- = {} d->priv: L+ = {}, L- = {} summary: d->priv->stats: L+ = {}, L- = {d->priv->lock} d->priv->f1: L+ = {d->priv->lock}, L- = {} d->priv: L+ = {}, L- = {} summary: row 1: reads only => no race row 2: common lock => no race row 3: no common lock => race

15 Modular Unsoundness  Pointer-arithmetic corner cases  Accesses in assembly code  Function pointers  Not enforcing must-alias for lockset intersection  Filters Revisit each and improve

16  Introduction  Computing locksets & recording accesses  Relative locksets  Guarded accesses  Experiments with Linux  Categorizing warnings: false positives  Filters targeting categories Outline

17 Linux experiments  warnings  Sample 90 and categorize  Design and apply filters to zoom-in on races

18 Categories of false positives  Initialization: thread allocates object and initializes it before sharing  Aliasing: mixed up different data structures  Unsharing: objects removed from shared structures  Recursive locks: “ Big kernel lock”  Non-lock synchronization: spawn, wait, signal, etc.  Conditional locking: locking correlated with return value, conditionals, etc.

19 Example filter: Thread “ownership”  To reduce initialization false positives:  remove accesses originating from the thread that allocated the object. x = malloc()‏ init(x)‏ share(x)‏ update(x)‏ x = get()‏ update(x)‏ x = get()‏ update(x)‏ thread 1thread 2 thread 3 filtered

20 Before filters: 11% data races

21 After filters: 80% data races

22 initialization non-aliasing, unsharing recursive locks non-lock sync. The absolute numbers

23 Related Work  Dynamic techniques  Locksets and extensions [Savage et al. 97, Choi et al. 02, Yu et al. 05, Elmas et al. 07]  Atomicity [Flanagan et al. 04, Wang et al. 06]  Benign vs. harmful [Narayanasamy et al. 07]  Static techniques for Java  Type systems [Flanagan et al. 99, Boyapati et al. 02]  Aliasing, must-not aliasing [Naik et al. 06, 07]  Static techniques for C  Scalability, ranking [Engler et al. 03]  Aliasing and sharing [Pratikakis et al. 06, Kahlon et al. 07]

24 Summary  Relative locksets: Modular summary-based analysis  Can analyze 46K functions of Linux kernel  modular => parallelizable  on a grid of 32 cpus: approx. 5 hours  Modular unsoundness  finds 53 races (or 25 after all filters)  future work: better analyses, better filters  whether races are benign or not, is another question!