Download presentation
Presentation is loading. Please wait.
Published byShona Hutchinson Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.