7,646 research outputs found
A Study of Concurrency Bugs and Advanced Development Support for Actor-based Programs
The actor model is an attractive foundation for developing concurrent
applications because actors are isolated concurrent entities that communicate
through asynchronous messages and do not share state. Thereby, they avoid
concurrency bugs such as data races, but are not immune to concurrency bugs in
general. This study taxonomizes concurrency bugs in actor-based programs
reported in literature. Furthermore, it analyzes the bugs to identify the
patterns causing them as well as their observable behavior. Based on this
taxonomy, we further analyze the literature and find that current approaches to
static analysis and testing focus on communication deadlocks and message
protocol violations. However, they do not provide solutions to identify
livelocks and behavioral deadlocks. The insights obtained in this study can be
used to improve debugging support for actor-based programs with new debugging
techniques to identify the root cause of complex concurrency bugs.Comment: - Submitted for review - Removed section 6 "Research Roadmap for
Debuggers", its content was summarized in the Future Work section - Added
references for section 1, section 3, section 4.3 and section 5.1 - Updated
citation
Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers
© 2015 IEEE.Concurrency errors, such as data races, make device drivers notoriously hard to develop and debug without automated tool support. We present Whoop, a new automated approach that statically analyzes drivers for data races. Whoop is empowered by symbolic pairwise lockset analysis, a novel analysis that can soundly detect all potential races in a driver. Our analysis avoids reasoning about thread interleavings and thus scales well. Exploiting the race-freedom guarantees provided by Whoop, we achieve a sound partial-order reduction that significantly accelerates Corral, an industrial-strength bug-finder for concurrent programs. Using the combination of Whoop and Corral, we analyzed 16 drivers from the Linux 4.0 kernel, achieving 1.5 - 20× speedups over standalone Corral
Producing Scheduling that Causes Concurrent Programs to Fail
A noise maker is a tool that seeds a concurrent program with conditional synchronization primitives (such as yield()) for the purpose of increasing the likelihood that a bug manifest itself. This work explores the theory and practice of choosing where in the program to induce such thread switches at runtime. We introduce a novel fault model that classifies locations as .good., .neutral., or .bad,. based on the effect of a thread switch at the location. Using the model we explore the terms in which efficient search for real-life concurrent bugs can be carried out. We accordingly justify the use of probabilistic algorithms for this search and gain a deeper insight of the work done so far on noise-making. We validate our approach by experimenting with a set of programs taken from publicly available multi-threaded benchmark. Our empirical evidence demonstrates that real-life behavior is similar to what our model predicts
Symbolic Partial-Order Execution for Testing Multi-Threaded Programs
We describe a technique for systematic testing of multi-threaded programs. We
combine Quasi-Optimal Partial-Order Reduction, a state-of-the-art technique
that tackles path explosion due to interleaving non-determinism, with symbolic
execution to handle data non-determinism. Our technique iteratively and
exhaustively finds all executions of the program. It represents program
executions using partial orders and finds the next execution using an
underlying unfolding semantics. We avoid the exploration of redundant program
traces using cutoff events. We implemented our technique as an extension of
KLEE and evaluated it on a set of large multi-threaded C programs. Our
experiments found several previously undiscovered bugs and undefined behaviors
in memcached and GNU sort, showing that the new method is capable of finding
bugs in industrial-size benchmarks.Comment: Extended version of a paper presented at CAV'2
You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems
Properly benchmarking Automated Program Repair (APR) systems should
contribute to the development and adoption of the research outputs by
practitioners. To that end, the research community must ensure that it reaches
significant milestones by reliably comparing state-of-the-art tools for a
better understanding of their strengths and weaknesses. In this work, we
identify and investigate a practical bias caused by the fault localization (FL)
step in a repair pipeline. We propose to highlight the different fault
localization configurations used in the literature, and their impact on APR
systems when applied to the Defects4J benchmark. Then, we explore the
performance variations that can be achieved by `tweaking' the FL step.
Eventually, we expect to create a new momentum for (1) full disclosure of APR
experimental procedures with respect to FL, (2) realistic expectations of
repairing bugs in Defects4J, as well as (3) reliable performance comparison
among the state-of-the-art APR systems, and against the baseline performance
results of our thoroughly assessed kPAR repair tool. Our main findings include:
(a) only a subset of Defects4J bugs can be currently localized by commonly-used
FL techniques; (b) current practice of comparing state-of-the-art APR systems
(i.e., counting the number of fixed bugs) is potentially misleading due to the
bias of FL configurations; and (c) APR authors do not properly qualify their
performance achievement with respect to the different tuning parameters
implemented in APR systems.Comment: Accepted by ICST 201
- …