User-guided program reasoning using Bayesian inference

Automatic static detection of data races is one of the most basic problems in reasoning about concurrency. We present RacerDÐa static program analysis for detecting data races in Java programs which is fast, can scale to large code, and has proven effective in an industrial software engineering scenario. To our knowledge, RacerD is the first inter-procedural, compositional data race detector which has been empirically shown to have non-trivial precision and impact. Due to its compositionality, it can analyze code changes quickly, and this allows it to perform continuous reasoning about a large, rapidly changing codebase as part of deployment within a continuous integration ecosystem. In contrast to previous static race detectors, its design favors reporting high-confidence bugs over ensuring their absence. RacerD has been in deployment for over a year at Facebook, where it has flagged over 2500 issues that have been fixed by developers before reaching production. It has been important in enabling the development of new code as well as fixing old code: it helped support the conversion of part of the main Facebook Android app from a single-threaded to a multi-threaded architecture. In this paper we describe RacerD's design, implementation, deployment and impact.

Section: Static Race Detectorsmentioning

confidence: 99%

“…We used the benchmarks that were used to evaluate Chord in the context of the Bingo work (Raghothaman et al 2018). The chosen programs are all concurrent applications from different domains.…”

Section: Static Race Detectorsmentioning

confidence: 99%

RacerD: compositional static race detection

Blackshear

Gorogiannis

O’Hearn

et al. 2018

“…In this section we place RacerDX in the field of static race detectors that have been subjected to formal analysis. Since the majority of the static race analyzers used in industry-ThreadSafe (Atkey and Sannella 2015), Coverity's analysis suite (Chou 2014), and RacerD (Blackshear et al 2018)despite being impactful in practice, do not come with any formal theorem about their algorithm, we focus on the only two race analyzers we know of, for which a formal statement has been made: Chord (Naik et al 2006;Raghothaman et al 2018) and RacerDX. Chord is a tool which strives to be sound, or to favour reduction of false negatives over false positives.…”

Section: Discussion and Related Workmentioning

confidence: 99%

“…For analyzers that come with a proof of soundness, the criterion often used is that of precision, i.e., that the analyzer does not report too many false positives. The rate of true positives can be improved by chaining the main analysis with a suitably tailored pre-analysis (Oh et al 2014), or by involving a user into the loop and taking her feedback into account (Raghothaman et al 2018).…”

Section: Discussion and Related Workmentioning

confidence: 99%

A true positives theorem for a static race detector

Gorogiannis

O’Hearn

Sergey

2019

RacerD is a static race detector that has been proven to be effective in engineering practice: it has seen thousands of data races fixed by developers before reaching production, and has supported the migration of Facebook's Android app rendering infrastructure from a single-threaded to a multi-threaded architecture. We prove a True Positives Theorem stating that, under certain assumptions, an idealized theoretical version of the analysis never reports a false positive. We also provide an empirical evaluation of an implementation of this analysis, versus the original RacerD.The theorem was motivated in the first case by the desire to understand the observation from production that RacerD was providing remarkably accurate signal to developers, and then the theorem guided further analyzer design decisions. Technically, our result can be seen as saying that the analysis computes an underapproximation of an over-approximation, which is the reverse of the more usual (over of under) situation in static analysis. Until now, static analyzers that are effective in practice but unsound have often been regarded as ad hoc; in contrast, we suggest that, in the future, theorems of this variety might be generally useful in understanding, justifying and designing effective static analyses for bug catching.RacerD is not sound in the sense of computing an over-approximation of some abstraction of executions. Over-approximations support a theorem: if the analyzer says there are no bugs, then there are none. I.e., there are no false negatives (when the program has no bugs), which is often considered as a "soundness" theorem. RacerD favours reducing false positives over false negatives. A design goal was to "detect actionable races that developers find useful and respond to" but "no need to (provably) find them all". In fact, it is very easy to generate artificial false negatives, but Blackshear et al. (2018) say that few have been reported in over a year of RacerD in production.One can react to this by saying that RacerD is simply an ad hoc, if effective, tool. But, the tool does not heuristically filter out bug reports in order to reduce false positives. It first does computations with an abstract domain, and then issues data race reports if any potential races are found according to the abstract domain. Its architecture is like that of a principled analyzer based on abstract interpretation, even though it does not satisfy the usual soundness theorem. This suggests that saying RacerD is ad hoc because it does not satisfy a standard soundness theorem is somehow missing something: It would be better if a demonstrably-effective analyzer with a principled design came with a theoretical explanation, even if partial, for its effectiveness. That is the research problem we set ourselves to solve in this work.A natural question is if it is possible to actually modify RacerD so as to make it sound, without losing its effectiveness in generating signal-actionable and useful data race reports that developers are keen to fix. RacerD's initial d...

“…There have been several recent successes in applying (supervised) machine learning to programming languages research. For example, machine learning has been used to infer program invariants [Padhi et al 2016;, improve program analysis [Liang et al 2011;Mangal et al 2015;Raghothaman et al 2018;Raychev et al 2015] and synthesis [Balog et al 2016;Feng et al 2018Kalyan et al 2018;Lee et al 2018;Raychev et al 2016b;Schkufza et al 2013Schkufza et al , 2014, build probabilistic models of code [Bielik et al 2016;Raychev et al 2016aRaychev et al , 2014, infer specifications [Bastani et al 2017[Bastani et al , 2018bBeckman and Nori 2011;Bielik et al 2017;Heule et al 2016;Kremenek et al 2006;Livshits et al 2009], test software [Clapp et al 2016;Godefroid et al 2017;Liblit et al 2005], and select lemmas for automated Proof. First, because transitions are deterministic, we have…”

Section: Related Workmentioning

confidence: 99%

Relational verification using reinforcement learning

Chen

Wei

et al. 2019

Relational verification aims to prove properties that relate a pair of programs or two different runs of the same program. While relational properties (e.g., equivalence, non-interference) can be verified by reducing them to standard safety, there are typically many possible reduction strategies, only some of which result in successful automated verification. Motivated by this problem, we propose a new relational verification algorithm that learns useful reduction strategies using reinforcement learning. Specifically, we show how to formulate relational verification as a Markov decision process (MDP) and use reinforcement learning to synthesize an optimal policy for the underlying MDP. The learned policy is then used to guide the search for a successful verification strategy. We have implemented this approach in a tool called Coeus and evaluate it on two benchmark suites. Our evaluation shows that Coeus solves significantly more problems within a given time limit compared to multiple baselines, including two state-of-the-art relational verification tools. CCS Concepts: • Software and its engineering → Software verification; • Theory of computation → Reinforcement learning.