90 likes | 222 Views
This course focuses on advanced topics in software engineering, particularly software testing and analysis. Key subjects include random testing, refactoring, static analysis, and model checking. Students will engage with influential papers, discussing their merits and limitations while identifying potential projects. The course will emphasize real-world applications of static analysis and its effectiveness in bug detection across various programming contexts. Through collaboration and in-depth discussions, participants will enhance their understanding of these crucial software engineering concepts.
E N D
CS527: Advanced Topics in Software Engineering(Software Testing and Analysis) Darko Marinov September 11, 2008
Schedule • Aug 26 & 28: Intro, reading/writing papers • Sep 2: Random testing • Sep 4: Refactoring (Jeff Overbey) • Sep 9: Testing refactoring engines • TODAY: Sep 11: Static analysis (more votes) • Sep 16: Model checking (fewer votes) • Sep 18 (and on): Testing (most votes)
Paper Reports • Continue with four items for a while: • One good point • One bad point • One potential project • Goal: help you identify your projects • One question for discussion • If sent early, may be discussed in class • Looking for depth • No need to make reports (too) long
Paper Today • Checking System Rules Using System-Specific, Programmer-Written Compiler Extensionsby Dawson Engler, Benjamin Chelf, Andy Chou, Seth Hallem (OSDI 2000) • One in a series of papers on meta-level compilation • Slides from Dawson Engler’s web page
Brief Summary • Motivation • Use system-specific rules to check for bugs • Approach • Allow the programmer to specify the rules succinctly using a new language (metal) • Later work: infer rules automatically from the code • Automatically check the specified rules • Results (this paper) • 500+ correctness errors in four real systems • Some optimization improvements for FLASH
Some Terms • No need to remember details; the point: there’re many approaches to static analysis • Abstract Interpretation • Dataflow Analysis • Flow-sensitive vs. flow-insensitive • Intra-procedural vs. inter-procedural • Context-sensitive vs. context-insensitive • “Data flow analysis is model checking of abstract interpretations” by David Schmidt(PLDI 1998)
Your Questions (1) • What are we expected to get from this paper? • How to detect/prevent false positives? • Could code inspection or other practices (better) find these bugs? • How did they make the rules for different languages? • What are the limitations of this checking? • What time it takes to check typical software? • How to know if compiler works correctly? [PP]
Your Questions (2) • Can static analysis be used… • …for commercial programs with unusual or highly specific business rules? [YYL] • …in other field (say refactoring engine)? [DY] • …during the software design process to improve quality and minimize errors? [DH] • …for other potential uses (of the metal SMs)? • Is the proposed approach really better than automatic testing? [ST] • How are static analysis and testing used in practice? [WX]
More Questions • How the flow graph was generated to find the blocking routines in Linux (Section 6.1)? • How hard is it to write the checkers? • Can MC go across function boundary? • Catches only 1 double lock and 1 double unlock bug in Linux? • Why syntactical and not semantical? • Large number of false positives?