RacerD - Compositional Static Race Detection
summary
RacerD is a compositional static race detector that builds compositional interprocedural summaries of syntactic accesses and uses ownership and thread domains plus lock counts to decide races, favoring high-confidence bug reports over soundness. It runs in CI against millions of lines, with median analysis about 11 minutes (mean 22.5), flags ~2,500 issues in deployment, and helped fix thousands of races during a major Android background-thread migration. Benchmarks show far fewer alarms than prior static tools and comparable or better true-bug recall than dynamic tools.
AI-written summary · about
chapters (11)
- 0:00Start
- 1:02Moving layout to background for better perf
- 2:02Adding concurrency can introduce data races
- 3:03Adding concurrency to sequential code is scary
- 4:49Devs need static analysis for migration
- 5:05Stringent requirements for helpful analysis
- 7:24Background: compositional analysis
- 8:58Example: computing summaries + reporting
- 14:20Conditional ownership: owned if formals are
- 16:45Racer vs sound static and dynamic analysis tools
- 20:27Conclusion
related talks
22mData race detection
32mEventRacer: Finding Concurrency Errors in Event-Driven Applications
15mSound and partially-complete static analysis of data-races in GPU programs
17mSSRD: Shapes and Summaries for Race Detection in Concurrent Data Structures
44m"go test -race" Under the Hood
32mMaTSa: Race Detection in Java
19mRuntime Detection of Data Races in OCaml with ThreadSanitizer
16mThemis: Detecting Distributed Concurrency Bugs through RPC-Driven Race-Directed Test...