Anomaly-based bug prediction, isolation, and validation

Dimitrov, Martin; Zhou, Huiyang

doi:10.1145/1508284.1508252

Cited by 5 publications

(10 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The baseline run of MySQL3 finishes in 0.46 seconds. In total, ConSeq took 10.6 seconds for the validation step for all 15 …”

Section: Performance Resultsmentioning

confidence: 99%

“…Backward analysis might be straightforward for failure replay and diagnosis [1,15,46,58,65] when the failure has already occurred. However, it is much more difficult for bugdetection and testing, where we need to identify potential points of bugs and failures.…”

Section: Concurrency and Sequential Bugs Have Drastically Different Cmentioning

confidence: 99%

“…Failure-diagnosis and repeating The consequence-oriented approach in ConSeq is similar in flavor to failure-diagnosis/replay tools [1,15,46,58,65]. For example, slicing is a useful technique in both cases [15,58,65].…”

Section: Related Workmentioning

confidence: 99%

“…For example, slicing is a useful technique in both cases [15,58,65]. The heuristic of paying more attention to the code close to a (potential) failure site is also widely used [46,58,65].…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

ConSeq

et al. 2011

View full text Add to dashboard Cite

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 observation that 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. * (a) This bug is not a race; it is an atomicity violation [33,56] (b) This bug is not atomicity violation or race;it is an order violation [32] (c) This is not a traditional bug; it is a multi-variable synchronization problem [31,35]

show abstract

“…The baseline run of MySQL3 finishes in 0.46 seconds. In total, ConSeq took 10.6 seconds for the validation step for all 15 …”

Section: Performance Resultsmentioning

confidence: 99%

Section: Concurrency and Sequential Bugs Have Drastically Different Cmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

“…For example, slicing is a useful technique in both cases [15,58,65]. The heuristic of paying more attention to the code close to a (potential) failure site is also widely used [46,58,65].…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

ConSeq

et al. 2011

View full text Add to dashboard Cite

show abstract

“…General software failure diagnosis The effect-oriented approach used in ConMem shares a similar flavor with failure diagnosis tools [10,45]. These tools look for the root causes of observed failures through data slicing.…”

Section: Concurrent Programs' Empirical Studymentioning

confidence: 99%

ConMem

Zhang

Sun

2010

SIGPLAN Not.

View full text Add to dashboard Cite

Multicore technology is making concurrent programs increasingly pervasive. Unfortunately, it is difficult to deliver reliable concurrent programs, because of the huge and non-deterministic interleaving space. In reality, without the resources to thoroughly check the interleaving space, critical concurrency bugs can slip into production runs and cause failures in the field. Approaches to making the best use of the limited resources and exposing severe concurrency bugs before software release would be desirable.Unlike previous work that focuses on bugs caused by specific interleavings (e.g., races and atomicity-violations), this paper targets concurrency bugs that result in one type of severe effects: program crashes. Our study of the error-propagation process of realworld concurrency bugs reveals a common pattern (50% in our non-deadlock concurrency bug set) that is highly correlated with program crashes. We call this pattern concurrency-memory bugs: buggy interleavings directly cause memory bugs (NULL-pointerdereference, dangling-pointer, buffer-overflow, uninitialized-read) on shared memory objects.Guided by this study, we built ConMem to monitor program execution, analyze memory accesses and synchronizations, and predicatively detect these common and severe concurrency-memory bugs. We also built a validator ConMem-v to automatically prune false positives by enforcing potential bug-triggering interleavings.We evaluated ConMem using 7 open-source programs with 9 real-world severe concurrency bugs. ConMem detects more tested bugs (8 out of 9 bugs) than a lock-set-based race detector and an unserializable-interleaving detector that detect 4 and 5 bugs respectively, with a false positive rate about one tenth of the compared tools. ConMem-v further prunes out all the false positives. Con-Mem has reasonable overhead suitable for development usage.

show abstract

Lightweight Automatic Error Detection by Monitoring Collar Variables

Domingues

Abreu

2012

Testing Software and Systems

View full text Add to dashboard Cite

Although proven to be an effective way for detecting errors, generic program invariants (also known as fault screeners) entail a considerable runtime overhead, rendering them not useful in practice. This paper studies the impact of using simple variable patterns to detect the so-called system's collar variables to reduce the number of variables to be monitored (instrumented). Two different patterns were investigated to determine which variables to monitor. The first pattern finds variables whose value increase or decrease at regular intervals and deems them not important to monitor. The other pattern verifies the range of a variable per (successful) execution. If the range is constant across executions, then the variable is not monitored. Experiments were conducted on three different real-world applications to evaluate the reduction achieved on the number of variables monitored and determine the quality of the error detection. Results show a reduction of 52.04% on average in the number of monitored variables, while still maintaining a good detection rate with only 3.21% of executions detecting non-existing errors (false positives) and 5.26% not detecting an existing error (false negatives).

show abstract

Anomaly-based bug prediction, isolation, and validation

Cited by 5 publications

References 35 publications

ConSeq

ConSeq

ConMem

Lightweight Automatic Error Detection by Monitoring Collar Variables

Contact Info

Product

Resources

About