Presentation is loading. Please wait.

Presentation is loading. Please wait.

Effective Static Deadlock Detection Mayur Naik, Chang-Seo Park, Koushik Sen and David Gay ICSE’09 Presented by Alex Kogan 27.04.2014.

Similar presentations


Presentation on theme: "Effective Static Deadlock Detection Mayur Naik, Chang-Seo Park, Koushik Sen and David Gay ICSE’09 Presented by Alex Kogan 27.04.2014."— Presentation transcript:

1 Effective Static Deadlock Detection Mayur Naik, Chang-Seo Park, Koushik Sen and David Gay ICSE’09 Presented by Alex Kogan

2 Outline Introduction Suggested Solution Evaluation Related work Conclusions Discussion

3 Introduction

4 What is a Deadlock? An unintended condition in a shared-memory, multi-threaded program in which: – a set of threads block forever – because each thread in the set waits to acquire a lock being held by another thread in the set

5 Example // thread t1 sync (l1) { sync (l2) { … } // thread t2 sync (l2) { sync (l1) { … } l1 t1 l2 t2

6 Motivation Today’s concurrent programs are rife with deadlocks – 6,500 (~3%) of bugs reported in Sun’s bug database are deadlocks Difficult to detect – Triggered non deterministically on specific thread schedules – Fail-stop behavior not guaranteed Fixing other concurrency bugs like races can introduce new deadlocks

7 Previous Work Dynamic approaches – Unsound – Inapplicable to open programs – Rely on input data Static approaches(Soundness) – Type systems – Model checking – Dataflow analysis

8 Challenges t1 l1 l2 t1 l1 l2 t2 l4 l3 t2

9 Example: jdk1.4 java.util.logging t1 t2 l4 l3 l2 l1

10 Solution Outline List set of conditions for a deadlock Check each condition separately Utilize existing static analyses for each condition Report candidates that satisfy all conditions Only find deadlocks involving 2 locks(threads)

11 Solution Java deadlock detection algorithm

12 Take II: Effective Static Deadlock Detection Mayur Naik, Chang-Seo Park, Koushik Sen and David Gay ICSE’09 Presented by Alex Kogan

13 Context Context in the seminar – Concurrency present challenges – We have seen mostly C analyses OO?

14 Object-Sensitivity Invented by A. Milanova et al. [ISSTA 2002] Produces points-to and call graph

15 Related Work Anderson’s Algorithm – Flow & context insensitive – Base for speed & accuracy comparison Flow Sensitivity (k) CFA – Control Flow Analysis – Context sensitive

16 Idea OO paradigm presents special needs – Objects play a major role – Call graph defined by inheritance Fast (practical) Adjustable

17 Object Sensitivity Comparable to CFA – Uses the receiver object instead of the caller Saves up to k receiving (this) objects Uses them to calculate the context of each pointer

18 Example: Object-Sensitive Analysis class Y extends X {} class A { X f; void m(X q) { this.f=q ; }} A a = new A() ; a.m(new X()) ; A aa = new A() ; aa.m(new Y()) ; o2o2 f o1o1 a this A.m o1o1 q A.m o1o1 this A.m.f=q o1o1 o1o1 this.f=q ; o3o3 aa o4o4 o3o3 this A.m o3o3 q A.m this A.m.f=q o3o3 o3o3 f

19 Example: Object-Sensitive Analysis Loss Of Information for k=1 o3o3 f o1o1 a this A.m o1o1 q A.m o1o1 o2o2 aa o3o3 o2o2 this A.m o2o2 q A.m f class A { X f; void m(A q) { this.f=q ; }} A[] a= new A[2]; a[0] = new A() ; a[1] = new A() ; for(int i=0; i<2; i++) a[i].m(new A()) ; a[0].f.m(new A()) ; o4o4 o3o3 q A.m f f

20 Example: Object-Sensitive Analysis Success For k=2 o3o3 f o1o1 a this A.m o1o1 q A.m o1o1 o2o2 aa o3o3 o2o2 this A.m o2o2 q A.m f class A { X f; void m(A q) { this.f=q ; }} A[] a= new A[2]; a[0] = new A() ; a[1] = new A() ; for(int i=0; i<2; i++) a[i].m(new A()) ; a[0].f.m(new A()) ; o4o4 o3,o1o3,o1 q A.m f

21 k-Object-Sensitivity Computation Starting point – consider main method and class initializers reachable. Add points-to for every new object (at local var v) – objects created in context c = (o = [h 1,…, h k ], m) add ((o,m), v, [this, h 1, …, h k-1 ]) Add to call graph for every method call – for a instance method call v.n(...) add ([h 1,…, h k ], n’) for context in which v is reachable if n’= m start then also deem reachable n’’ = m run for a static method call n(..) add ([], n)

22 k-Object-Sensitivity Cont.

23 Building Call Graph & Points To class Y extends X {} class A { X f; void m(X q) { this.f=q ; } A a = new A() ; a.m(new X()) ; A aa = new A() ; aa.m(new Y()) ; this A.m.f=q o1o1 o1o1 this.f=q ;this A.m.f=q o3o3 o3o3 (([], m main ), v 1, [h 1 ]) (([], m main ), v 3, [h 3 ]) (([h 1 ], m), v 2, [h 2 ]) (([], m main ), ([h 1 ], m)) Points-To Call Graph (([], m main ), ([h 3 ], m)) (([h 3 ], m), v 2, [h 4 ])

24 Example: jdk1.4 java.util.logging t1 t2 l4 l3 l2 l1

25 Example: Step 1 pt = {(([], m main ), v 1, [h 1 ]), (([], m main ), v 2, [h 2 ])} cg = {(([], m main ), ([h 1 ], m start )), (([], m main ), ([h 2 ], m start ))} Deem reachable – ([h 1 ], m 4 ) – ([h 2 ], m 5 ) – m 4, m 5 are the run methods of the threads

26 Example: Step 2* – What is added to the call graph? (([h 1 ], m 4 ) x ([], m 1 )) – Logger.getLogger() (([h 2 ], m 5 ) x ([h 3 ], m 2 )) – LogManager.lm.addLogger() – How about point-to? Nothing new to be added in this step Next step will add all local variables of functions getLogger() and addLogger()

27 Object Sensitivity: Analysis Time (k=2)

28 A Word About Precision: Modified Objects Per Statement jbjesssableccraytraceAverage OBJECT SENSITIVE ANDERSEN

29 For The Main Event Deadlock Detection

30 A Deadlock l1 t1 l2 t2

31 Deadlock Computation (Java)

32

33 Call Graph vs Threads & Locks m main … h 2 m run h 1 m run h 2 m start h 2 m start h 3 m add [] m get …… …

34 Example: jdk1.4 java.util.logging t1 t2 l4 l3 l2 l1

35 Deadlock computation example

36 Deadlock Computation - Tuples

37 Sound conditions for deadlock original tuples Reachable tuples Aliasing tuples Escaping tuples Parallel tuples All Deadlocks

38 Unsound conditions for deadlock Parallel tuples All True deadlocks Reentrant tuples Guarded tuples

39 In some execution: – can a thread abstracted by t1 reach l1 – and after acquiring lock at l1, proceed to reach l2 while holding that lock? – and similarly for t2, l3, l4 Solution: Use call-graph analysis Condition 1: Reachable t1 l1 l2 t1 l1 l2 l4 l3 t2 l4 l3 t2

40 Reachable Cont.

41 Condition 2: Aliasing In some execution: – can a lock acquired at l1 be the same as a lock acquired at l4? – and similarly for l2, l3 Solution: Use may-alias analysis l1 l2 t1 l1 l2 l4 l3 t2

42 Aliasing Cont.

43 Condition 3: Escaping In some execution: – can a lock acquired at l1 be thread-shared? – and similarly for each of l2, l3, l4 Solution: Use thread-escape analysis l1 l2 t1 l1 l2 l4 l3 l4 l3 t2

44 Escaping Analysis Gist

45 Escaping Cont.

46 Example: jdk1.4 java.util.logging t1 t2 l4 l3 l2 l1

47 Condition 4: Parallel In some execution: – can different threads abstracted by t1 and t2 – simultaneously reach l2 and l4? Solution: Use may-happen-in-parallel analysis ≠ t1 l1 l2 t1 l1 l2 l4 l3 t2 l4 l3 t2

48 May-happen-in-parallel Gist

49 May-happen-in-parallel Cont.

50 Condition 5: Non-reentrant Property: In some execution: – can a thread abstracted by t1 acquire a non-reentrant lock at l1 – and, while holding that lock, proceed to acquire a non-reentrant lock at l2? – and similarly for t2, l3, l4 Solution: Use call-graph + may-alias analysis – Unsound: Negation of over-approximation ≠≠ t1 l1 l2 t1 l1 l2 l4 l3 t2 l4 l3 t2

51 Non-reentrant Cont.

52 Reentrant examples

53 Condition 6: Non-guarded In some execution: – can different threads abstracted by t1 and t2 reach l1 and l3, respectively, without holding a common lock? Solution: Use call-graph + may-alias analysis – Unsound: Same as for condition 5. lg t1 l1 l2 t1 l1 l2 l4 l3 t2 l4 l3 t2

54 Non-guarded Cont.

55 Example: jdk1.4 java.util.logging t1 t2 l4 l3 l2 l1

56 Recap k-object-sensitivity – call graph – points-to (may-alias) Deadlock conditions Some other analyses – thread-escape – may-happen-in-parallel Correctness – unsound(last two) – incomplete

57 Sound conditions for deadlock original tuples Reachable tuples Aliasing tuples Escaping tuples Parallel tuples All Deadlocks

58 Unsound conditions for deadlock Parallel tuples All True deadlocks Reentrant tuples Guarded tuples

59 Post Processing Providing a counter example(path) for each deadlock – look like a stack trace – Shortest path between each lock acquisition – May be infeasible Grouping of counterexamples – Running Example: Same lock types Group both tuples together

60 Output example Deadlock Reports Group 1 Report 1 Thread spawned by method java.lang.Thread.start() in context [main]java.lang.Thread.start() Thread spawned by method java.lang.Thread.start() in context [main]java.lang.Thread.start() Lock held at T.java:24 in context [main] allocated at {[java. lang. Object]}T.java:24java. lang. Object Lock held at T.java:34 in context [main] allocated at {[java. lang. Object]}T.java:34java. lang. Object Lock held at T.java:29 in context [main] allocated at {[java. lang. Object]}T.java:29java. lang. Object Lock held at T.java:39 in context [main] allocated at {[java. lang. Object]}T.java:39java. lang. Object [Shortest path from thread root to first lock] [Shortest path from first lock to second lock]Shortest path from thread root to first lockShortest path from first lock to second lock [Shortest path from thread root to first lock] [Shortest path from first lock to second lock]Shortest path from thread root to first lockShortest path from first lock to second lock Source:

61 Implementation JADE – Soot framework to make initial 0-CFA – Rewrite synchronized blocks to methods – Convert to SSA for percision k-object-sensitivity – Iteration and refinement – Stop conditions

62 Evaluation

63 BenchmarkLOCClassesMethodsSyncsTime moldyn31, m48s montecarlo157, m53s raytracer32, m51s tsp154, m48s sor32, m48s hedc160, m15s weblech184, m02s jspider159, m34s jigsaw154, m23s ftp180, m55s dbcp168, m04s cache4j34, m43s logging167, m01s collections38, m42s Benchmarks

64 BenchmarkDeadlocks (0-cfa) Deadlocks (k-obj.) Lock type pairs (total) Lock type pairs (real) moldyn0000 montecarlo0000 raytracer0000 tsp0000 sor0000 hedc7,5522, weblech4, jspider jigsaw ftp16,2593, dbcp cache4j0000 logging4, collections Experimental Results (k=1)

65 Individual Analyses Contributions

66

67 Evaluation Conclusions Java.logging is(was) a mess Conditions are useful for reducing false positives Found all known deadlocks and some new ones – “Effective in practice”

68 Related Work

69 Static Analyses Type Systems – SafeJava – Annotation burden Model Checking – Promela/SPIN – finate-state

70 Static Analyses Cont. Dataflow Analysis – LockLint/Jlint augmentation – 0-CFA without parallel, escaping, guarded [Von Praum, 2008] – Lock-order graph + heuristics [A. Williams, 2005] – RacerX – flow sensitive, imprecise, hueristics – Sound, Ada [S. Masticola, 1993]

71 Dynamic Analysis Approaches – Visual Threads – Goodlock algorithm Inherently unsound Require test input data

72 Conclusions Object sensitivity for object sensitive idioms – Scalable, Precise Novel approach to static deadlock detection for Java – Use off-the-shelf static analyses Effective static analysis is possible – If we specialize in a given setting – And sacrifice soundness and/or completeness

73 Running Chord Chord is the open source tool that implements this algorithm (among others) Running on my code – Found 3 “possible”, out of them 2 were deadlocks Running on latest versions of JDK and some others – No deadlocks found Searching for deadlock reports – Going back to the versions that had bugs (reported) – Found 6/7 deadlocks that were reported and accepted

74 My* Idea Hybrid approach Compute possible paths – Use static analysis to compute a sound approximation Remove false positives using dynamic approaches – Try to run the trace output – Schedule the threads to create a deadlock. Remove most false-positive (noise), but keep soundness

75 My* Idea: Related Work An effective dynamic analysis for detecting generalized deadlocks. [P. Joshi, M. Naik, K. Sen, and D. Gay. FSE 2010] Jnuke [C. Artho, A. Biere. 2005] ConLock [Y. Cai, S. Wu, W. Chan. 2014]

76 Questions?

77 Discussion Will you use it? Sacrificing soundness, is it a big deal? How about JavaScript? – Field sensitivity?


Download ppt "Effective Static Deadlock Detection Mayur Naik, Chang-Seo Park, Koushik Sen and David Gay ICSE’09 Presented by Alex Kogan 27.04.2014."

Similar presentations


Ads by Google