Lightweight data race detection for production runs

Abstract

To detect data races that harm production systems, program analysis must target production runs. However, sound and precise data race detection adds too much run-time overhead for use in production systems. Even existing approaches that provide soundness or precision incur significant limitations.This work addresses the need for soundness (no missed races) and precision (no false races) by introducing novel, efficient production-time analyses that address each need separately. (1) Precise data race detection is useful for developers, who want to fix bugs but loathe false positives. We introduce a precise analysis called RaceChaser that provides low, bounded run-time overhead.(2) Sound race detection benefits analyses and tools whose correctness relies on knowledge of all potential data races. We present a sound, efficient approach called Caper that combines static and dynamic analysis to catch all data races in observed runs. Race-Chaser and Caper are useful not only on their own; we introduce a framework that combines these analyses, using Caper as a sound filter for precise data race detection by RaceChaser.Our evaluation shows that RaceChaser and Caper are efficient and effective, and compare favorably with existing state-of-the-art approaches. These results suggest that RaceChaser and Caper enable practical data race detection that is precise and sound, respectively, ultimately leading to more reliable software systems.

Efficient noise injection for exposing hidden data races

“…Static race detection Numerous studies have been performed to find potential races in source codes, but they have produced many false alarms [31,39,41,42,49]. Therefore, the results of most of the static analyses have only been used for optimizing dynamic analyses [3,43,53].…”

Dependence-aware, unbounded sound predictive race detection

“…The detected races thus depend heavily on the scheduling of the analyzed program. Other analyses find a subset of HB-races by detecting simultaneously executing conflicting accesses or regions [Biswas et al 2017Effinger-Dean et al 2012;Erickson et al 2010;Sen 2008;Veeraraghavan et al 2011].…”

“…Sampling-based analysis trades coverage for performance (opposite of predictive analysis) in order to detect data races in production [Biswas et al 2017;Bond et al 2010;Erickson et al 2010;Kasikci et al 2013;Marino et al 2009;Sheng et al 2011;. Custom hardware support can detect data races with low performance cost but has not been implemented [Devietti et al 2012;Lucia et al 2010;Marino et al 2010;Peng et al 2017;Segulja and Abdelrahman 2015;Wood et al 2014;Zhou et al 2007].…”

“…Static program analysis can detect all races across all feasible executions of a program [Engler and Ashcraft 2003;Naik and Aiken 2007;Naik et al 2006;Pratikakis et al 2006;von Praun and Gross 2003;Voung et al 2007], but it reports thousands of false races for real programs [Biswas et al 2017;Lee et al 2012].…”

Performance Evaluation of Data Race Detection Based on Thread Sharing Analysis With Different Granularities: An Empirical Study

“…For example, Nishiyama [21], Christiaens and Bosschere [22] used dynamic escape analysis (DEA) to improve the performance of race detection. Compared with first-shared-access-based DEA [4], [21]- [23], reachability-based DEA [22], [24], [25] has more advantage to be a sound filter for data race detection. Recent work introduced a lightweight data race detection Caper for production runs [25].…”