staticdetec.pptVIP

RacerX: effective, static detection of race conditions and deadlocks Dawson Engler and Ken Ashcraft Stanford University The problem. Big picture: Races and deadlocks are bad. Hard to get w/ testing: depend on low-probability events. Want to get rid of them. Main games in town have problems. Language: Mesa, Java, various type systems. Forced to use language; still have errors Tools: Dynamic (Eraserco): must execute code: no run, no bug. Static (ESC, Warlock): High annotation overhead. Static dynamic high false positive rates. RacerX: lightweight checking for big code Goal: As many bugs as possible with as little help as possible Works on real million line systems Low annotation overhead (100 lines per system) Aggressively infers checking information. Unusual techniques to reduce false positives. The RacerX experience How to use: List locking functions entry points. Small: Linux: 18 + 31, FreeBSD: 30 + 36, System X: 50 + 52 Emit trees from source code (2x cost of compile) Run RacerX over emitted trees Links all trees into global control flow graph (CFG) Checks for deadlocks races ~2-20 minutes for Linux. Post-process to rank errors (most of IQ spent here) Inspect Talk Overview Context RacerX overview Context-sensitive, flow-sensitive lockset analysis. Deadlock checking Race detection. Conclusion. Lockset analysis Lockset: set of locks currently held [Eraser] For each root, do a flow-sensitive, inter-procedural DFS traversal computing lockset at each statement Speed: If stmt s was visited before with lockset ls, stop. Inter-procedural: Routine can exit with multiple locksets: resume DFS w/ each after callsite. Record in-ls, {out-ls} in fn summary. If ls in summary, grab cached out-ls’s and skip fn body. Lockset Lockset Talk Overview Context RacerX overview Static lockset analysis Deadlock checking Race detection. Conclusion. Big picture: Deadlock detection Pass 1: constraint extraction emit 1-level locking dependencies during loc