Experiencesusingstaticanalysismodelcheckingforbug.pptVIP

Experiences using static analysis model checking for bug finding Dawson Engler and Madanlan Musuvathi Based on work with Andy Chou, David {Lie, Park, Dill} Stanford University Context: bug finding in implementation code Goal: find as many bugs as possible. Not verification, not checking high level design Two promising approaches Static analysis Software model checking. Basis: used static analysis extensively for four years; model checking for several projects over two years. General perception: Static analysis: easy to apply, but shallow bugs Model checking: harder, but strictly better once done. Reality is a bit more subtle. This talk is about that. Quick, crude definitions. “Static analysis” = our approach [DSL’97,OSDI’00] Flow-sensitive, inter-procedural, extensible analysis Goal: max bugs, min false pos May underestimate work factor: not sound, no annotation Works well: 1000s of bugs in Linux, BSD, company code Expect similar tradeoffs to PREfix, SLAM(?), ESP(?) “Model checker” = explicit state space model checker Use Murphi for FLASH, then home-grown for rest. May underestimate work factor: All case studies use techniques to eliminate need to manually write model. Some caveats Talk bias: OS designer who does static analysis and has been involved in some some model checking Some things that surprise me will be obvious to you. Of course, is just a bunch of personal case studies tarted up with engineers induction to look like general principles. (1,2,3=QED) Coefficients may change, but general trends should hold Not a jeremiad against model checking! We want it to succeed. Will write more papers on it. Life has just not always been exactly as expected. The Talk An introduction Case 1: FLASH cache coherence protocol code Checked statically [ASPLOS’00], then model checked [ISCA’01] Surprise: static found 4x more bugs. Case 2: AODV loop free, ad-hoc routing protocol Checked w/ model checking [OSDI’02]