1. Soyeon Park, Shan Lu, Yuanyuan Zhou UIUC Reading Group by Theo

2.  Concurrency bugs really hard to detect ◦ And to reliably reproduce  Usually caused by atomicity violation ◦ Programmer failed to enforce atomicity correctly 2 if (buf_index+len<BUF_MAX) memcpy(&buf[buf_index],log,len); buf_index+=len; (expectation of atomicity) Thread 1Thread 2 Expected ExecutionActual Execution

3.  Stress testing ◦ Rerun multiple times with same input to find concurrency bugs ◦ It only tests the same probable interleavings  Black bar shows identical portion of execution ◦ Good luck with reproducing the bug 3

4. 4

5.  RaceFuzzer ◦ Use a race detector to detect races  For each detected race, try different interleavings ◦ What if race is not detected?  CHESS ◦ Run one thread/time (as RaceFuzzer) ◦ Switch threads on sync points to expose bugs ◦ Limits coverage 5

6.  Focus on unserializable interleavings ◦ Most concurrency bugs are hidden here  Check cases that the stress test didn’t cover ◦ CTrigger expands tiny windows of vulnerability to find well-hidden bugs  If bug is detected, replay is very easy ◦ We know which windows were expanded 6

7.  Introduction ◦ Motivation ◦ Existing Solutions ◦ Proposed Solution  Background ◦ Unserializability  CTrigger  Evaluation  Conclusion 7

8.  Definitions ◦ Current: instr that we examine now with mem ◦ Previous: prev instr in SAME thread for SAME mem ◦ Remote: instr on OTHER thread for SAME mem  Accesses to mem is serializable if we can say (P→C) → R or R →(P → C) ◦ Remote did not get in the middle ◦ One thread at a time 8

9.  CTrigger tries to exercise at least one unseria- lizable interleaving for each instruction C ◦ But not for each dynamic instance of C 9

10.  Introduction  Background  Ctrigger ◦ High Level View ◦ Analysis Phase ◦ Testing Phase  Evaluation  Conclusion 10

11. 11 For each test input

12.  Done using PIN  Collect all shared-memory accesses ◦ Use that to identify P, R instruction for each shared memory access  If found, we have a potential unserializable interleaving  Record critical calls such as fork, barrier, lock, malloc ◦ Remember locks held for each thread 12

13.  Infeasible interleavings are ignored ◦ Based on fork/joins and barriers  R cannot run before C, because R-thread is created after C ◦ Based on locking schema  P and C are in same critical section, and thread holds some keys needed by R’s critical section ◦ Based on memory allocations  R cannot interfere with C, because addr x was freed after C and malloc’ed before R. Not same x 13

14.  CTrigger tries to enforce interleavings that the stress test failed to execute  Prioritize cases with small local gap, large re- mote distance and few dynamic instances of C ◦ More likely for the stress test to not exercise them 14

15.  For each C, try to enforce each type of unserializability at least once  Insert delays before C or R to force the opposite resolution of the race  Done with PIN 15

16. 16

17.  Introduction  Background  Ctrigger  Evaluation ◦ Evaluated Apps, bugs ◦ Speed and Efficiency  Conclusion 17

18. 18

19. 19

20. 20

21.  Seconds to find bug ◦ NO: not found in 1 day for Apache, MySQL, Mozilla, 12 hours for other apps  Found 1 previously unknown bug in macro library of SPASH2 & 4 new buggy code regions in Apache 21

22. 22 CTrigger always fastest or second fastest in reproducing bug

23. 23

24. 24 Bugs usually hiding in unlikely interleavings

25. 25

26. 26 Significant number of interleavings proven to be infeasible

27.  Nice method of exposing concurrency bugs ◦ At least the ones based on atomicity violation ◦ With an automated procedure  Able to detect previously unknown bugs  Can reproduce bug reliably for debugging  Questions? 27