Results 1 - 10
of
11
IFRit: Interference-Free Regions for Dynamic Data-Race Detection ∗
"... We propose a new algorithm for dynamic data-race detection. Our algorithm reports no false positives and runs on arbitrary C and C++ code. Unlike previous algorithms, we do not have to instrument every memory access or track a full happens-before relation. Our data-race detector, which we call IFRit ..."
Abstract
-
Cited by 12 (3 self)
- Add to MetaCart
(Show Context)
We propose a new algorithm for dynamic data-race detection. Our algorithm reports no false positives and runs on arbitrary C and C++ code. Unlike previous algorithms, we do not have to instrument every memory access or track a full happens-before relation. Our data-race detector, which we call IFRit, is based on a run-time abstraction called an interference-free region (IFR). An IFR is an interval of one thread’s execution during which any write to a specific variable by a different thread is a data race. We insert instrumentation at compile time to monitor active IFRs at run-time. If the runtime observes overlapping IFRs for conflicting accesses to the same variable in two different threads, it reports a race. The static analysis aggregates information for multiple accesses to the same variable, avoiding the expense of having to instrument every memory access in the program. We directly compare IFRit to FastTrack [10] and Thread-Sanitizer [25], two state-of-the-art fully-precise data-race detectors. We show that IFRit imposes a fraction of the overhead of these detectors. We show that for the PARSEC benchmarks, and several real-world applications, IFRit finds many of the races detected by a fully-precise detector. We also demonstrate that sampling can further reduce IFRit’s performance overhead without completely forfeiting precision. ∗ This material is based upon work supported by the National Science
ConMem: Detecting Crash-Triggering Concurrency Bugs through an Effect-Oriented Approach
"... 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 conc ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
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 versions 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 effect: program crashes. Our study of the error-propagation process of real-world 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-pointer-dereferences, dangling-pointers, buffer-overflows, uninitialized-reads) on shared memory objects. Guided by this study, we built ConMem to monitor program execution, analyze memory accesses and synchronizations, and predictively 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 10 real-world concurrency bugs. ConMem detects more tested bugs (9 out of 10 bugs) than a lock-set-based race detector and an unserializableinterleaving detector, which detect 4 and 6 bugs, respectively, with a false-positive rate about one tenth of the compared tools. ConMem-v further prunes out all the false positives. ConMem has reasonable overhead suitable for development usage.
Griffin: Grouping Suspicious Memory-Access Patterns to Improve Understanding of Concurrency Bugs
, 2013
"... This paper presents Griffin, a new fault-comprehension technique. Griffin provides a way to explain concurrency bugs using additional information over existing fault-localization techniques, and thus, bridges the gap between fault-localization and fault-fixing techniques. Griffin inputs a list of me ..."
Abstract
- Add to MetaCart
(Show Context)
This paper presents Griffin, a new fault-comprehension technique. Griffin provides a way to explain concurrency bugs using additional information over existing fault-localization techniques, and thus, bridges the gap between fault-localization and fault-fixing techniques. Griffin inputs a list of memory-access patterns and a coverage matrix, groups those patterns responsible for the same concurrency bug, and outputs the grouped patterns along with suspicious methods and bug graphs. Griffin is the first technique that handles multiple concurrency bugs. This paper also describes the implementation of Griffin in Java and C++, and shows the empirical evaluation of Griffin on a set of subjects. The results show that, for our subjects, Griffin clusters failing executions and memory-access patterns for the same bug with few false positives, provides suspicious methods that contain the locations to be fixed, and runs efficiently.
Abstract Interference-Free Regions and Their Application to Compiler Optimization and Data-Race Detection
, 2012
"... Programming languages must be defined precisely so that programmers can reason carefully about the behavior of their code and language implementers can provide correct and efficient compilers and interpreters. However, until quite recently, mainstream languages such as Java and C++ did not specify e ..."
Abstract
- Add to MetaCart
(Show Context)
Programming languages must be defined precisely so that programmers can reason carefully about the behavior of their code and language implementers can provide correct and efficient compilers and interpreters. However, until quite recently, mainstream languages such as Java and C++ did not specify exactly how programs that use shared-memory multithreading should behave (e.g., when do writes by one thread become visible to another thread?). The memory model of a programming language addresses such questions. The recently-approved memory model for C++ effectively requires programs to be “data-racefree”: all executions of the program must have the property that any conflicting memory accesses in different threads are ordered by synchronization. To meet this requirement, programmers must ensure that threads properly coordinate accesses to shared memory using synchronization mechanisms such as mutual-exclusion locks. We introduce a new abstraction for reasoning about data-race-free programs: interferencefree regions. An interference-free region, or IFR, is a region surrounding a memory access during which no other thread can modify the accessed memory location without causing a data race. Specifically, the interference-free region for a memory access extends from the
Greedy Coherence
"... Atomicity violations and violations of sequential consistency are two broad classes of concurrency errors that reduce the reliability of software. These failures often occur when different processors interleave their memory accesses at a fine grain. Greedy Coherence (GreCo) is a simple hardware tech ..."
Abstract
- Add to MetaCart
(Show Context)
Atomicity violations and violations of sequential consistency are two broad classes of concurrency errors that reduce the reliability of software. These failures often occur when different processors interleave their memory accesses at a fine grain. Greedy Coherence (GreCo) is a simple hardware technique that delays responses to some coherence requests to make this kind of sharing coarser, separating different processors ’ accesses to the same memory location in time. These delays avoid operation interleavings that lead to some atomicity violations and sequential consistency (SC) violations, making software more robust to these types of faults. We describe two implementations of GreCo: one that monitors coherence protocol messages and uses additional hardware structures to identify and avoid likely atomicity and SC violations; and a lowercomplexity implementation that leverages the existing processor write buffer and focuses mainly on avoiding SC violations. Simulation results show that GreCo avoids failures in several bug kernel programs and incurs a negligible performance impact—less than 2%—on programs from the PARSEC benchmark suite. 1.
Concurrency Debugging with Differential Schedule Projections
"... We present Symbiosis: a concurrency debugging technique based on novel differential schedule projections (DSPs). A DSP shows the small set of memory operations and data-flows responsible for a failure, as well as a reordering of those elements that avoids the failure. To build a DSP, Symbiosis first ..."
Abstract
- Add to MetaCart
(Show Context)
We present Symbiosis: a concurrency debugging technique based on novel differential schedule projections (DSPs). A DSP shows the small set of memory operations and data-flows responsible for a failure, as well as a reordering of those elements that avoids the failure. To build a DSP, Symbiosis first generates a full, failing, multithreaded schedule via thread path profiling and symbolic con-straint solving. Symbiosis selectively reorders events in the failing schedule to produce a non-failing, alternate schedule. A DSP re-ports the ordering and data-flow differences between the failing and non-failing schedules. Our evaluation on buggy real-world software and benchmarks shows that, in practical time, Symbiosis generates DSPs that both isolate the small fraction of event orders and data-flows responsible for the failure, and show which event reorderings prevent failing. In our experiments, DSPs contain 81 % fewer events and 96 % fewer data-flows than the full failure-inducing schedules. Moreover, by allowing developers to focus on only a few events, DSPs reduce the amount of time required to find a valid fix.
Slope-based Sequencing Yardstick for Analyzing Unsatisfactory performance of multithreaded programs An SSYAU Trend Estimation Approach to Performance Bug Localization*
"... Abstract—As users are increasingly concerned about energy efficiency, they are also increasingly intolerant of performance anomalies of programs that may cause significant energy waste. Bug localization is a bottleneck in the development of multi-threaded programs. Although both static and dynamic p ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—As users are increasingly concerned about energy efficiency, they are also increasingly intolerant of performance anomalies of programs that may cause significant energy waste. Bug localization is a bottleneck in the development of multi-threaded programs. Although both static and dynamic perfor-mance bug localization techniques have been proposed, they cannot handle performance anomalies with unforeseen patterns, and cannot work well if the concept of performance anomaly is fuzzy or evolves over time for the same program. We propose a novel model-based approach to performance bug localization. The approach is based on curve fitting and trend estimation over program executions with performance data. We describe our trend estimation model and illustrate it with the result of a case study on locating three real-world performance bugs in MySQL. Keywords—performance bug, model-based approach, multi-threaded program, bug localization I.
Predicting Concurrency Bugs: How Many, What Kind and Where Are They?
"... Concurrency bugs are difficult to find and fix. To help with finding and fixing concurrency bugs, prior research has mostly focused on static or dynamic analyses for finding spe-cific classes of bugs. We present an approach whose focus is understanding the differences between concurrency and non-con ..."
Abstract
- Add to MetaCart
(Show Context)
Concurrency bugs are difficult to find and fix. To help with finding and fixing concurrency bugs, prior research has mostly focused on static or dynamic analyses for finding spe-cific classes of bugs. We present an approach whose focus is understanding the differences between concurrency and non-concurrency bugs, the differences among various con-currency bug classes, and predicting bug quantity, type, and location, from patches, bug reports and bug-fix met-rics. First, we show that bug characteristics and bug-fixing processes vary significantly among different kinds of concur-rency bugs and compared to non-concurrency bugs. Next, we build a quantitative predictor model to estimate concur-rency bugs appearance in future releases. Then, we build a qualitative predictor that can predict the type of concur-rency bug for a newly-filed bug report. Finally, we build a bug location predictor to indicate the likely source code loca-tion for newly-reported bugs. We validate the effectiveness of our approach on three popular projects, Mozilla, KDE, and Apache. 1.
Automatically finding atomic regions for fixing bugs in Concurrent programs
"... ar ..."
(Show Context)
Using Web Corpus Statistics for Program Analysis
"... Several program analysis tools—such as plagiarism detec-tion and bug finding—rely on knowing a piece of code’s relative semantic importance. For example, a plagiarism de-tector should not bother reporting two programs that have an identical simple loop counter test, but should report pro-grams that ..."
Abstract
- Add to MetaCart
Several program analysis tools—such as plagiarism detec-tion and bug finding—rely on knowing a piece of code’s relative semantic importance. For example, a plagiarism de-tector should not bother reporting two programs that have an identical simple loop counter test, but should report pro-grams that share more distinctive code. Traditional program analysis techniques (e.g., finding data and control dependen-cies) are useful, but do not say how surprising or common a line of code is. Natural language processing researchers have encountered a similar problem and addressed it using an n-gram model of text frequency, derived from statistics computed over text corpora. We propose and compute an n-gram model for program-ming languages, computed over a corpus of 2.8 million JavaScript programs we downloaded from the Web. In con-trast to previous techniques, we describe a code n-gram as a subgraph of the program dependence graph that contains all nodes and edges reachable in n steps from the statement. We can count n-grams in a program and count the frequency of n-grams in the corpus, enabling us to compute tf-idf-style measures that capture the differing importance of different lines of code. We demonstrate the power of this approach by implementing a plagiarism detector with accuracy that beats previous techniques, and a bug-finding tool that discovered over a dozen previously unknown bugs in a collection of real deployed programs. 1.
