Demo Data from EDBT 2026 / reviewers in the wild / expert
Chris Blinn
dblp:31/10322
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2011
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Concurrent programming · 44% Debugging and program repair · 44% Operating systems · 13% |
Topics — the 3 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Concurrent programming › concurrency bug detection
data race detection |
0.1 | 1 | 2011 | Pervasive detection of process races in deployed systems · SOSP 2011 |
Debugging and program repair
fault localization |
0.1 | 1 | 2011 | Pervasive detection of process races in deployed systems · SOSP 2011 |
Operating systems › operating system interface › system call
system call interposition |
0.0 | 1 | 2011 | Pervasive detection of process races in deployed systems · SOSP 2011 |
Methods — techniques the papers use, named apart from their topics
record and replay · 0.1deterministic replay · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2011 | Finding Concurrency Errors in Sequential Code - OS-level, In-vivo Model Checking of Process Races
Oren Laadan, Chia-Che Tsai, Nicolas Viennot, Chris Blinn, Peter Senyao Du, Jason Nieh |
HotOS | 4 |
| 2011 | Pervasive detection of process races in deployed systemsabstractProcess races occur when multiple processes access shared operating system resources, such as files, without proper synchronization. We present the first study of real process races and the first system designed to detect them. Our study of hundreds of applications shows that process races are numerous, difficult to debug, and a real threat to reliability. To address this problem, we created RacePro, a system for automatically detecting these races. RacePro checks deployed systems in-vivo by recording live executions then deterministically replaying and checking them later. This approach increases checking coverage beyond the configurations or executions covered by software vendors or beta testing sites. RacePro records multiple processes, detects races in the recording among system calls that may concurrently access shared kernel objects, then tries different execution orderings of such system calls to determine which races are harmful and result in failures. To simplify race detection, RacePro models under-specified system calls based on load and store micro-operations. To reduce false positives and negatives, RacePro uses a replay and go-live mechanism to distill harmful races from benign ones. We have implemented RacePro in Linux, shown that it imposes only modest recording overhead, and used it to detect a number of previously unknown bugs in real applications caused by process races. Oren Laadan, Nicolas Viennot, Chia-Che Tsai, Chris Blinn, Jason Nieh |
SOSP | 4 |