ConSeq

Abstract

Concurrency bugs are caused by non-deterministic interleavings between shared memory accesses. Their effects propagate through data and control dependences until they cause software to crash, hang, produce incorrect output, etc. The lifecycle of a bug thus consists of three phases: (1) triggering, (2) propagation, and (3) failure. Traditional techniques for detecting concurrency bugs mostly focus on phase (1)--i.e., on finding certain structural patterns of interleavings that are common triggers of concurrency bugs, such as data races. This paper explores a consequence-oriented approach to improving the accuracy and coverage of state-space search and bug detection. The proposed approach first statically identifies potential failure sites in a program binary (i.e., it first considers a phase (3) issue). It then uses static slicing to identify critical read instructions that are highly likely to affect potential failure sites through control and data dependences (phase (2)). Finally, it monitors a single (correct) execution of a concurrent program and identifies suspicious interleavings that could cause an incorrect state to arise at a critical read and then lead to a software failure (phase (1)). ConSeq's backwards approach, (3)!(2)!(1), provides advantages in bug-detection coverage and accuracy but is challenging to carry out. ConSeq makes it feasible by exploiting the empirical observationthat phases (2) and (3) usually are short and occur within one thread. Our evaluation on large, real-world C/C++ applications shows that ConSeq detects more bugs than traditional approaches and has a much lower false-positive rate.

Refactoring traces to identify concurrency improvements

“…Whereas Rehype focuses on performance and is purely dynamic-analysis-based, much of the existing work on concurrency analysis focuses on detecting concurrency-based bugs such as race conditions [1,2,7], deadlocks [1], and more-general thread-safety violations [3,6]. Most approaches are either based on static analysis [7], potentially with subsequent confirmation via dynamic analysis [14] or a hybrid approach [1], or use dynamic analysis such as execution-replay [10] or execution-modification [6] (such as injected delays) to trigger bugs. While there are some primarily dynamic analysis-based approaches (e.g.…”

Source code patches from dynamic analysis

“…Furthermore, given its unified approach (as opposed to, for example, overlay graphs), the APG is particularly well suited to algorithms that combine analysis and transformation. Some existing work combines static analysis and dynamic analysis for the detection of bugs [2,14], especially multi-threading bugs which are particularly difficult to find with static analysis alone. Such work combines static analysis and dynamic analysis to enhance the analysis (detection) process, whereas Scopda combines them to translate dynamic analysis identified improvements back into the static domain (source code).…”