A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Pallavi Joshi  Chang-Seo Park  Koushik Sen  Mayur Naik ‡  Par Lab, EECS, UC Berkeley‡

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

Ditto: Speeding Up Runtime Data Structure Invariant Checks AJ Shankar and Ras Bodik 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.
Runtime Verification Ali Akkaya Boğaziçi University.
Race Directed Random Testing of Concurrent Programs KOUSHIK SEN - UNIVERSITY OF CALIFORNIA, BERKELEY PRESENTED BY – ARTHUR KIYANOVSKI – TECHNION, ISRAEL.
A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Koushik Sen CS 265.
Simulation Verification of Different Constraints in System Level Design in SystemC Piyush Ranjan Satapathy CS220 Class Project Presentation.
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
Prof. Moonzoo Kim Computer Science, KAIST
The Path to Multi-core Tools Paul Petersen. Multi-coreToolsThePathTo 2 Outline Motivation Where are we now What is easy to do next What is missing.
Atomicity in Multi-Threaded Programs Prachi Tiwari University of California, Santa Cruz CMPS 203 Programming Languages, Fall 2004.
Big Picture Lab 4 Operating Systems Csaba Andras Moritz.
PARALLEL PROGRAMMING with TRANSACTIONAL MEMORY Pratibha Kona.
Precise Inter-procedural Analysis Sumit Gulwani George C. Necula using Random Interpretation presented by Kian Win Ong UC Berkeley.
Mayur Naik Alex Aiken John Whaley Stanford University Effective Static Race Detection for Java.
Synchronization in Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
02/17/2010CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Cormac Flanagan UC Santa Cruz Velodrome: A Sound and Complete Dynamic Atomicity Checker for Multithreaded Programs Jaeheon Yi UC Santa Cruz Stephen Freund.
02/19/2007CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
/ PSWLAB Eraser: A Dynamic Data Race Detector for Multithreaded Programs By Stefan Savage et al 5 th Mar 2008 presented by Hong,Shin Eraser:
Threads in Java1 Concurrency Synchronizing threads, thread pools, etc.
University of Michigan Electrical Engineering and Computer Science 1 Practical Lock/Unlock Pairing for Concurrent Programs Hyoun Kyu Cho 1, Yin Wang 2,
15-740/ Oct. 17, 2012 Stefan Muller.  Problem: Software is buggy!  More specific problem: Want to make sure software doesn’t have bad property.
University of Michigan Electrical Engineering and Computer Science 1 Dynamic Acceleration of Multithreaded Program Critical Paths in Near-Threshold Systems.
Accelerating Precise Race Detection Using Commercially-Available Hardware Transactional Memory Support Serdar Tasiran Koc University, Istanbul, Turkey.
Threads. Overview Problem Multiple tasks for computer Draw & display images on screen Check keyboard & mouse input Send & receive data on network Read.
Quick overview of threads in Java Babak Esfandiari (extracted from Qusay Mahmoud’s slides)
1 Effective Static Race Detection for Java Mayur, Alex, CS Department Stanford University Presented by Roy Ganor 14/2/08 Point-To Analysis Seminar.
Deadlock Detection Nov 26, 2012 CS 8803 FPL 1. Part I Static Deadlock Detection Reference: Effective Static Deadlock Detection [ICSE’09]
Eraser: A Dynamic Data Race Detector for Multithreaded Programs STEFAN SAVAGE, MICHAEL BURROWS, GREG NELSON, PATRICK SOBALVARRO, and THOMAS ANDERSON Ethan.
Lecture 2 Foundations and Definitions Processes/Threads.
Pallavi Joshi* Mayur Naik † Koushik Sen* David Gay ‡ *UC Berkeley † Intel Labs Berkeley ‡ Google Inc.
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.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Synchronized and Monitors. synchronized is a Java keyword to denote a block of code which must be executed atomically (uninterrupted). It can be applied.
15.1 Threads and Multi- threading Understanding threads and multi-threading In general, modern computers perform one task at a time It is often.
Deadlock Analysis with Fewer False Positives Thread T1: sync(G){ sync(L1){ sync(L2){} } }; T3 = new T3(); j3.start(); J3.join(); sync(L2){ sync(L1){} }
Ali Kheradmand, Baris Kasikci, George Candea Lockout: Efficient Testing for Deadlock Bugs 1.
Virtual Application Profiler (VAPP) Problem – Increasing hardware complexity – Programmers need to understand interactions between architecture and their.
CSE 60641: Operating Systems Next topic: CPU (Process/threads/scheduling, synchronization and deadlocks) –Why threads are a bad idea (for most purposes).
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
Effective Static Deadlock Detection Mayur Naik* Chang-Seo Park +, Koushik Sen +, David Gay* *Intel Research, Berkeley + UC Berkeley.
CAPP: Change-Aware Preemption Prioritization Vilas Jagannath, Qingzhou Luo, Darko Marinov Sep 6 th 2011.
Sampling Dynamic Dataflow Analyses Joseph L. Greathouse Advanced Computer Architecture Laboratory University of Michigan University of British Columbia.
Deadlock Bug Detection Techniques Prof. Moonzoo Kim CS KAIST CS492B Analysis of Concurrent Programs 1.
Grigore Rosu Founder, President and CEO Professor of Computer Science, University of Illinois
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.
Aritra Sengupta, Man Cao, Michael D. Bond and Milind Kulkarni PPPJ 2015, Melbourne, Florida, USA Toward Efficient Strong Memory Model Support for the Java.
Reachability Testing of Concurrent Programs1 Reachability Testing of Concurrent Programs Richard Carver, GMU Yu Lei, UTA.
Testing Concurrent Programs Sri Teja Basava Arpit Sud CSCI 5535: Fundamentals of Programming Languages University of Colorado at Boulder Spring 2010.
Big Picture Lab 4 Operating Systems C Andras Moritz
1 Active Random Testing of Parallel Programs Koushik Sen University of California, Berkeley.
Java Thread Programming
Detecting Data Races in Multi-Threaded Programs
Concurrency 2 CS 2110 – Spring 2016.
Effective Data-Race Detection for the Kernel
runtime verification Brief Overview Grigore Rosu
Ravi Mangal Mayur Naik Hongseok Yang
Amir Kamil and Katherine Yelick
Threads Chate Patanothai.
Monitoring Programs using Rewriting
Multithreaded Programming
Amir Kamil and Katherine Yelick
50.530: Software Engineering
Ho-Ramamoorthy 2-Phase Deadlock Detection Algorithm
Foundations and Definitions
Presentation transcript:

A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Pallavi Joshi  Chang-Seo Park  Koushik Sen  Mayur Naik ‡  Par Lab, EECS, UC Berkeley‡ Intel Research, Berkeley

Goal Build a deadlock detection tool that – Scales to very large programs – Finds deadlocks quickly – Has no false positives Shows a real execution exhibiting a deadlock

Finding Deadlocks: Stress Testing Stress Testing + Easy to deploy + Scales to large programs + No false positives -Same schedule gets tested many times  No effort to control thread scheduler - Often subtle thread schedules that exhibit deadlocks are not tested

Finding Deadlocks: Random testing Removes some of the limitations of stress testing – Randomizes the thread scheduler Does not find deadlocks quickly – Deadlocks often happen under subtle schedules

Finding Deadlocks: Program Analysis Static program analysis + Examines all possible program behavior -Often reports many false positives Dynamic program analysis + Usually reports lesser false positives - Has false negatives

In Summary Random testing is simple, yet effective – No false positives But, may miss subtle thread schedules that result in deadlocks Static and dynamic program analyses have false positives

In Summary Random testing is simple, yet effective But, may miss subtle thread schedules that result in deadlocks How do we leverage random testing to quickly find deadlocks under subtle schedules?

Example Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ }

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Random Testing f1() f2() Lock(o2) Lock(o1) Unlock(o1) Unlock(o2)

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Random Testing Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Random Testing Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) f1() f2() No deadlock detected

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations f1(); f2(); } synchronized(l1){ synchronized(l2){ } Deadlock Directed Testing Lock(o2) Lock(o1) Paused f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations f1(); f2(); } synchronized(l1){ synchronized(l2){ } Deadlock Directed Testing Lock(o2) Lock(o1) Paused f1() f2() Lock(o1) Lock(o2) Paused

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations f1(); f2(); } synchronized(l1){ synchronized(l2){ } Deadlock Directed Testing Lock(o2) Lock(o1) Paused f1() f2() Lock(o1) Lock(o2) Paused

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations f1(); f2(); } synchronized(l1){ synchronized(l2){ } Deadlock Directed Testing Lock(o2) Lock(o1) Paused f1() f2() Lock(o1) Lock(o2) Paused Deadlock detected !

Preempting threads How do we know where to pause a thread ?

Preempting threads How do we know where to pause a thread ? – Use existing static or dynamic analyses to find potential deadlock cycles Note that these analyses may report false deadlock cycles – Use “information” recorded for a deadlock cycle to decide where to pause a thread – We use a modified version of the Goodlock algorithm (iGoodlock) [Havelund et al, Agarwal et al]

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2()

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2() Deadlock cycle detected by iGoodlock

Thread 1Thread 2 Thread1 foo(o1,o2,true) Thread2 foo(o2,o1,false) void foo(Object l1, Object l2, boolean flag) { if(flag) { // Long running computations s1: f1(); s2: f2(); } s3: synchronized(l1){ s4: synchronized(l2){ } Lock(o1) Lock(o2) Unlock(o2) Unlock(o1) Lock(o2) Lock(o1) Unlock(o1) Unlock(o2) Preempting threads f1() f2() Deadlock cycle (“information” recorded):,

Preempting threads T1, o1, T2, o2 are runtime objects How do we identify them across executions ?

Preempting threads T1, o1, T2, o2 are runtime objects How do we identify them across executions ? – Runtime addresses?

Preempting threads T1, o1, T2, o2 are runtime objects How do we identify them across executions ? – Runtime addresses? No, they change across executions !

Preempting threads T1, o1, T2, o2 are runtime objects How do we identify them across executions ? – Runtime addresses? No, they change across executions ! – Allocation sites where they were created ? Yes, but different objects created at the same allocation site will all be treated as the same object

Preempting threads T1, o1, T2, o2 are runtime objects How do we identify them across executions ? – Runtime addresses? No, they change across executions ! – Allocation sites where they were created ? Yes, but different objects created at the same allocation site will all be treated as the same object – Can we do better?

Abstractions Based on k-object sensitivity [Milanova et al] Based on light-weight execution indexing [Xin et al]

Abstractions 7 class A { 8 void bar() { 9 for(int j = 0; j < 5; j++) 10 Object l = new Object(); 11 } 12 } 1 class C { 2 void foo() { 3 A a = new A(); 4 a.bar(); 5} 6 } 13 main() { 14 C c = new C(); 15 for(int i = 0; i < 5; i++) 16 c.foo(); 17 } Abstraction of last object created (k- object sensitivity) : [10,3, 14] Abstraction of last object created (execution indexing) : [(10,5),(4,1),(16,5)]

Implementation Implemented in a prototype tool called DEADLOCKFUZZER for Java Part of the CALFUZZER framework – Active random testing of concurrent programs Instrument Java bytecode to – observe events during execution – control scheduler

Evaluation Program Name Lines Of Code Average Runtime in milliseconds NormaliGoodlockDeadlockFuzzer cache4j3,8972,0453,409N.A. sor17, N.A. hedc25, ,668N.A. jspider10,2524,6225,020N.A. Jigsaw160, Java Logging4, Java Swing337,2914,6949,56328,052 DBCP27, ,393 Synchronized Lists 17,6332,8623,2447,070 Synchronized Maps 18,9112,2952,

Evaluation Program Name Lines Of Code # Deadlock CyclesProbability of Reproduction iGoodlockRealReproduced cache4j3,89700N.A. sor17,71800N.A. hedc25,02400N.A. jspider10,25200N.A. Jigsaw160, ≥ Java Logging4, Java Swing337, DBCP27, Synchronized Lists 17, Synchronized Maps 18,

Evaluation

Limitations If DEADLOCKFUZZER does not reproduce a deadlock, we cannot say if the deadlock is a false positive or not Jigsaw – Deadlocks reported by iGoodlock : 283 – Deadlocks reproduced by DEADLOCKFUZZER : 29 – Deadlocks confirmed as false positives : 18 – Rest : 236

Limitations If DEADLOCKFUZZER does not reproduce a deadlock, we cannot say if the deadlock is a false positive or not Jigsaw – Deadlocks reported by iGoodlock : 283 – Deadlocks reproduced by DEADLOCKFUZZER : 29 – Deadlocks confirmed as false positives : 18 – Rest : 236 Cannot say if they are real deadlocks or false warnings

Conclusion DEADLOCKFUZZER is a practical deadlock detection tool that – Scales to large programs – Finds deadlock quickly – Finds real deadlocks Complements static and dynamic analyses – Automatically confirms some of the real deadlocks