1 / 35

CS294-32: Dynamic Program Analysis, Testing, and Debugging

CS294-32: Dynamic Program Analysis, Testing, and Debugging. Lecture 1 Koushik Sen EECS, UC Berkeley. CS294-32: Dynamic Program Analysis, Model Checking, and Testing , and Debugging. Lecture 1 Koushik Sen EECS, UC Berkeley. My Background. Assistant Professor in CS since Fall 2006

mitch
Télécharger la présentation

CS294-32: Dynamic Program Analysis, Testing, and Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS294-32: Dynamic Program Analysis, Testing, and Debugging Lecture 1 KoushikSen EECS, UC Berkeley

  2. CS294-32: Dynamic Program Analysis, Model Checking, and Testing, and Debugging Lecture 1 KoushikSen EECS, UC Berkeley

  3. My Background • Assistant Professor in CS since Fall 2006 • Office:Parlab (581 Soda Hall) • Email: ksen@cs • Ph.D. and M.S. in Computer Science • University of Illinois at Urbana Champaign (2001-2006) • Spent 1 year in software industry as a software developer • B-Tech • IIT Kanpur (1995-1999) • Research Interests: • Software Engineering, • Programming Languages, and • Formal Methods • Verification, Testing, Model Checking, Program Analysis

  4. Please introduce yourselves

  5. Logistics

  6. Course Goals • To help students start research in the area of program analysis, testing, and debugging of sequential, concurrent, and distributed systems. • To help students to apply the techniques learned in this course in their ongoing research in other areas such as operating systems, computer networks, security, and database systems.

  7. Course Communication • All class materials will be on the website • http://sp09.pbwiki.com/ • See website for announcements • Class meets on Tuesday and Thursday, 1:00 PM – 2:30 PM at 310 Soda Hall • Office hour by appointment

  8. Course Structure • We will study papers • You will read a paper and write a review of the paper before each class • There will be around 14 guest lectures from the leading researchers in the area of programming languages and software engineering. • The guest lecturers include Thomas Ball, Byron Cook, DimitraGiannakopoulou, RanjitJhala, MadanMusuvathi, MayurNaik, CorinaPasareanu, and MoolySagiv. • You need to do 2-3 programming assignments • Test generation • Dynamic analysis of concurrent programs • Points-to analysis • Project in teams of 1-2.

  9. Course Grading • Reviews and class participation: 30% • 2-3 homework assignments: 30% • Project: 40% • A project must involve new research • Some sample projects will be posted online • Choose a project topic by 18thFebruary, 2009 • 1-2 page project proposal due by 20thFebruary, 2009 • A 5-7 minute mid-semester project presentation • Final project demo or presentation • 6 page project report in ACM SIGPLAN conference format

  10. About the course • This course is about software reliability • Why is software reliability important? • As society becomes more dependent on software, the consequences of software failures are non-trivial. • Money lost. • Lives lost. • Market share lost. • Clients lost. • Jobs lost.

  11. Software Bug => Space Disaster • Ariane 5 Space mission • $7, 000, 000, 000 • 10 Years in the making • 40 seconds after take off the rocket exploded

  12. Software Bug => Space Disaster Attempt to cram a 64-floating point number to a 16-bit integer failed

  13. On January 15, 1990, one of AT&T's #4ESS toll switching systems in New York City experienced an intermittent failure that caused a major service outage. Wrong BREAK statement in C-Code Complete coverage could have revealed this bug during testing /* ``C'' Fragment to Illustrate AT&T Defect */ do { switch expression { ... case (value): if (logical) { … break; } else { … } case (value2): … } … } while (expression) AT&T long distance service failed for 9 hours

  14. Software Bugs: Cause of Deaths • Several deaths of cancer patients were due to overdoses of radiation resulting from a race condition between concurrent tasks in the Therac-25 software.

  15. 180 Degree Bug Torpedoes, that deviate more than 90 degree, explode to avoid self destruction of the ship. Once upon a time a ship fired a torpedo but the torpedo was jammed in the tube. Then the captain gave the command: Let's turn around and return to the harbour! What happened next is no mystery.

  16. Cost of Failure • Software failures were estimated to cost the US economy about $60 billion annually [NIST 2002] • Improvements in software testing infrastructure may save one-third of this cost • Testing accounts for an estimated 50%-80% of the cost of software development [Beizer 1990]

  17. Methods for Building Reliable Software Safe Programming Languages and Type systems Testing Model Checking and Theorem Proving Static Program Analysis Dynamic Program Analysis Model Based Software Development and Analysis

  18. Methods for Building Reliable Software Safe Programming Languages and Type systems Testing Model Checking and Theorem Proving Static Program Analysis Dynamic Program Analysis Model Based Software Development and Analysis

  19. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  20. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  21. Automated Test Generation • 3 lectures • including one invited lecture on Symbolic Java Pathfinder from NASA Ames research center • Korat: • Reading assignment: Korat: Automated Testing Based on Java Predicates. Chandrasekhar Boyapati, SarfrazKhurshid, DarkoMarinov (ISSTA 2002) • Must submit review to the course wiki by 2/21 11:59 PM • Concolic Testing: Homework 1 • Symbolic Java Pathfinder

  22. Automated Test Generation • Generate test inputs • To reveal bugs: assertion violation, crashes, wrong output • Improve software reliability • Often cannot prove program correct • Need to check program for all possible inputs • Input domain is often infinite • Pick inputs to satisfy certain coverage criteria • Generate all legal inputs for bounded size • Generate all legal inputs for full branch coverage

  23. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  24. Software Model Checking • Attempt to prove programs correct • Abstract domain • Create an abstraction of the program • Show that the abstraction does not contain a “bad state” • Predicate abstraction and boolean programs • Successfully used for model checking device drivers

  25. Software Model Checking • 4 lectures including (1-2 invited lectures) • BLAST: Lazy abstraction • Decidability results for various boolean program models • Forms theoretical foundation of various software model checking algorithms • Pushdown systems • Pushdown systems with multiset • Petri-Nets • Multi-pushdown systems with bounded context switch

  26. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  27. Concurrent Program Analysis • Bugs due to concurrency are notorious • Intermittent and hard to reproduce • Common causes: data race, atomicity violations, deadlocks, and other synchronization issues • Much more difficult to analyze than sequential programs • Need to check program • all schedules • all inputs • Pushdown system with stacks => undecidable

  28. Concurrent Program Analysis • 5 lectures (including 2 invited lectures by Tom Ball and MadanMusuvathi) • Classic dynamic race detection algorithms • Atomicity checking and deadlock analysis • Explicit State Model Checking • Partial Order Reduction • Iterative context bounded model checking • Homework 2

  29. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  30. Abstract Interpretation and Points-to Anlaysis • 4 lectures (all invited lectures) • MoolySagiv on abstract interpretation • Note software model checking is an instantiation of abstract interpretation • forms basis of most static program analyses • MayurNaik on Points-to analysis • The most important analysis • Anderson’s points-to analysis • BDDs (Binary Decision Diagrams) for scalable points-to analysis • And a homework

  31. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  32. Terminator • 4 lectures by Byron Cook (MSR) • Static techniques to prove termination of system code

  33. Course Contents • Automated test generation • Software model checking and various theoretical results that form the foundation of software model checking • Concurrent program analysis • Abstract interpretation and points-to analysis • Scalable static termination detection • Compositional model checking

  34. Compositional Model Checking • 4 lectures by DimitraGiannakopoulou and CorinaPasareanu • Assume-guarantee reasoning • Automata learning and its application to assume guarantee reasoning

  35. Summary • 3 homework assignments will give you hands-on experience of program analysis • In my opinion, this is quite useful to get a deep understanding of the subject, and • to jump start research in program analysis

More Related