50.530 Exercise Solutions 2014 Fall Term. Week 2: Exercise 1 public static Boolean repOK(Stack mystack) { if (mystack.capacity() < 0) { return false;

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

50.530: Software Engineering
Semantics Static semantics Dynamic semantics attribute grammars
White Box and Black Box Testing Tor Stålhane. What is White Box testing White box testing is testing where we use the info available from the code of.
50.530: Software Engineering Sun Jun SUTD. Week 10: Invariant Generation.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
Reasoning About Code; Hoare Logic, continued
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
SE-1020 Dr. Mark L. Hornick 1 Exceptions and Exception Handling.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
FIT FIT1002 Computer Programming Unit 19 Testing and Debugging.
One of the most important problems is Computational Geometry is to find an efficient way to decide, given a subdivision of E n and a point P, in which.
Loops (Part 1) Computer Science Erwin High School Fall 2014.
Mock test review Revision of Activity Diagrams for Loops,
CSE115/ENGR160 Discrete Mathematics 04/12/11 Ming-Hsuan Yang UC Merced 1.
1 Pseudo-polynomial time algorithm (The concept and the terminology are important) Partition Problem: Input: Finite set A=(a 1, a 2, …, a n } and a size.
Testing an individual module
CSI 101 Elements of Computing Spring 2009 Lecture #5 Designing with Pseudocode Wednesday, February 4th, 2009.
DAST 2005 Tirgul 6 Heaps Induction. DAST 2005 Heaps A binary heap is a nearly complete binary tree stored in an array object In a max heap, the value.
50.530: Software Engineering
Reading and Writing Mathematical Proofs
Java Programming: From the Ground Up
Chapter 3 (Part 3): Mathematical Reasoning, Induction & Recursion  Recursive Algorithms (3.5)  Program Correctness (3.6)
© by Kenneth H. Rosen, Discrete Mathematics & its Applications, Sixth Edition, Mc Graw-Hill, 2007 Chapter 4 (Part 3): Mathematical Reasoning, Induction.
50.530: Software Engineering Sun Jun SUTD. Week 8: Race Detection.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Conditions. Objectives  Understanding what altering the flow of control does on programs and being able to apply thee to design code  Look at why indentation.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
Mr. Dave Clausen1 La Cañada High School Chapter 6: Repetition Statements.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
CSc2310 tutoring session, week 8 Fall, 2012 Haidong Xue 5:30pm—8:30pm 11/06/2012 and 11/07/2012 -Test 3 Study Guide.
Chapter 4 Loops Write code that prints out the numbers Very often, we want to repeat a (group of) statement(s). In C++, we have 3 major ways of.
An Introduction to Programming with C++ Sixth Edition Chapter 7 The Repetition Structure.
Control Structures II Repetition (Loops). Why Is Repetition Needed? How can you solve the following problem: What is the sum of all the numbers from 1.
Lazy Annotation for Program Testing and Verification Speaker: Chen-Hsuan Adonis Lin Advisor: Jie-Hong Roland Jiang November 26,
Recursive Algorithms &
Reasoning about programs March CSE 403, Winter 2011, Brun.
Design of Bio-Medical Virtual Instrumentation Tutorial 2.
Threads II IS Outline  Quiz  Thread review  Stopping a thread  java.util.Timer  Swing threads javax.swing.Timer  ProgressMonitor.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Pascal Programming Pascal Loops and Debugging. Pascal Programming Pascal Loops In our first brush with the while do loops, simple comparisons were used.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
1 Suppose I construct a TM M f which: 1. Preserves its input u. 2. Simulates a machine M b on input ε. 3. If M b hangs on input ε, force an infinite loop.
Model Counting with Applications to CodeHunt Willem Visser Stellenbosch University South Africa.
 Control Flow statements ◦ Selection statements ◦ Iteration statements ◦ Jump statements.
Calvin College Controlling Behavior The if, switch and for Statements.
CSC 213 – Large Scale Programming. Today’s Goal  Understand why testing code is important  Result of poor or no testing & embarrassment caused  Learn.
Loop Invariants and Binary Search Chapter 4.4, 5.1.
/ PSWLAB Evidence-Based Analysis and Inferring Preconditions for Bug Detection By D. Brand, M. Buss, V. C. Sreedhar published in ICSM 2007.
Week 9, Class 3: Java’s Happens-Before Memory Model (Slides used and skipped in class) SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors:
HW7: Due Dec 5th 23:59 1.Describe test cases to reach full path coverage of the triangle program by completing the path condition table below. Also, draw.
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
Flow Control in Imperative Languages. Activity 1 What does the word: ‘Imperative’ mean? 5mins …having CONTROL and ORDER!
Week 8, Class 3: Model-View-Controller Final Project Worth 2 labs Cleanup of Ducks Reducing coupling Finishing FactoryMethod Cleanup of Singleton SE-2811.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Let’s try it one more time!. Allan Technique Programming Recursively 1.Decide that the problem needs a recursive solution. 2.Decide specifically what.
Chapter 4 (Part 3): Mathematical Reasoning, Induction & Recursion
White-Box Testing Using Pex
Iteration with While You can say that again.
CSCI 3328 Object Oriented Programming in C# Chapter 4: C# Control Statement – Part I – Exercises UTPA – Fall 2012 This set of slides is revised from lecture.
Iteration: Beyond the Basic PERFORM
Algorithms Take a look at the worksheet. What do we already know, and what will we have to learn in this term?
CSC215 Lecture Flow Control.
CSC215 Lecture Control Flow.
Computer Science Core Concepts
50.530: Software Engineering
50.530: Software Engineering
Program correctness Axiomatic semantics
LOOPS The loop is the control structure we use to specify that a statement or group of statements is to be repeatedly executed. Java provides three kinds.
CSC215 Lecture Control Flow.
Presentation transcript:

Exercise Solutions 2014 Fall Term

Week 2: Exercise 1 public static Boolean repOK(Stack mystack) { if (mystack.capacity() < 0) { return false; } if (mystack.empty() != mystack.elements().hasMoreElements()) { return false; } if (mystack.isEmpty() && mystack.size() != 0) { return false; } //... return true; }

Week 2: Exercise 2 Valid test case: 1. OrdSet newobj = new OrdSet(5); 2. OrdSet newobj = new OrdSet(5); newobj. add(3); Redundant test case: OrdSet newobj = new OrdSet(5); newobj.toString(); Illegal test case: OrdSet newobj = new OrdSet(-1);

Week 3: Exercise 1 DD+({1..8}, {}, 2) DD+({1..8}, {}, 4) try again DD+({1..4,7,8}, {5,6}, 8) test({1..4}) =? = test({5...8}) test({5,6}) = PASS try again test({5,6,8}) = FAIL DD+({8}, {5,6}, 2) found in {8} return {8};

Week 3: Exercise 2 Use DDmin algorithm to minimize the input Cut the input in a half and test on the first half It fails and thus apply DDmin again and repeat. Once the minimum input is reached, identify the bug by tracing through the code based on the minimum test case.

Week 5: Exercise 1 Using Set Union: bug is at line 7 (since only line 7 is unique to the failed test case). Using Set Intersection: the result is {} and thus no predication.

Week 5: Exercise 2 Using Set Union: the result is {} and thus no predication. Using Set Intersection: the result is {} and thus no predication.

Week 5: Exercise 3 The nearest neighbor would be the second last test case and the predicate would be: line 7.

Week 5: Exercise 4 The nearest neighbor would be the first test case and the predicate would be: none.

Week 5: Exercise 5

Week 5: Exercise 6 To apply the method A/B/C/D, you need to instruct the program to monitor its execution (one for each block of code without any branches). None of the methods would locate the bug (for instance, method E would not work as the buggy line is not updating any variable) except perhaps method D (which depends on the test cases you generate).

Week 6: Exercise 1 The slice of the assertion includes all the statements.

Week 8: Exercise 1 Answer 1: No, there is no race condition according to the happens- before approach. Answer 2: Yes, there is a race condition on variable count (the first and last line).

Week 8: Exercise 2 The lockset algorithm finds the race condition at line 1 since count is a shared variable and it is accessed without any lock held (so that the intersection is {}).

Week 8: Exercise 3 For variable count, after the first count++, it moves from state Virgin to state Exclusive After the second count++, it moves from state Exclusive to Shared- Modified state since it is accessed by a new thread with write privilege. The checking then happens and since there is no lock held, a race condition is reported.

Week 8: Exercise 4 The report would be there is no race.

Week 8: Exercise 5 Lockset-based algorithm Race on x: line 10 and 1 Race on z: line 7 and 5 Happens-before filtering No race on Z since there is happens-before from unlock(L) to lock(L)

Week 8: Exercise 6 Assume that thread 1 is scheduled first, after executing line 1, it is postponed; Thread 2 is scheduled to run line 7 and then is blocked at line 8. Thread 1 moves on and thus no race is reported.

Week 9: Exercise 1 (3*y + z)*y - z > 0

Week 9: Exercise 2 5 * y - z > 0

Week 9: Exercise 3 We get the following Hoare triple first. {K>0&&M>0&&k=K&&m=M} while(k!=m) { if (k > m) {k = k-m;} else {m = m-k;} } {k=GCD(K,M)} We discharge it using the loop invariant: GCD(K, M) = gcd(k,m)

Week 9: Exercise 4 First row from left to right: yes, yes, no Second row from left to right: yes, yes, yes

Week 9: Exercise 5 For the inner loop, the ranking function is x-y and termination can be proved by establishing the following Hoare triple. {x-y=V&&y 0} y = 2*y {x-y < V} For the outer loop, the ranking function is x and termination can be proved by establishing the following Hoare triple {x>=0&&x=V} y := 1; while (y < x) { y = 2*y; } x = x – 1; {x < V} which can be proved using a loop invariant (i.e., x is unchanged) for the inner loop.

Week 10: Exercise 1 (Monday or Wednesday or Thursday) and (!Wednesday) and (!Friday) and (!Tuesday and !Thursday) SAT solving would lead to a solution: Monday = true; the rest = false;

Week 10: Exercise 2 The assertion can be demonstrated possible by symbolically executing the following path. !a && b && !a && c && y = 1 && z = 2 && !(x+y+z!=3) The solution is: a = false; b = true; c = true

Week 10: Exercise 3 Example: x+y<=4

Week 10: Exercise 4 Symbolic execution the left most path, apply interpolantion and get y>=1 at node 3. Skip the last alternative; backtrack … x = x+1 [y>=1]x = x+2 [y<1]x = x+4 * y<1 y>=1 44 [y>=1]x = x+2 y<1 [y<1]x = x+4 y>=1

Week 10: Exercise 5 The only exception that could rise at array[x]=2 when x = 0. Base case: assume input is false, the following is true: {x>=0}rec(){x>=0} which is basically {x>=0}x=x+1{x>=0} (*). Induction step: assume that {x>=0}rec(){x>=0}. {x>=0}rec(){x>=0} implies {x>=0}rec(); rec();{x>=0} (**). {x>=0} method-body {x>=0} since (*) and (**) {x>=0} rec() {x>=0}

Week 11: Exercise 1 We can prove that the error is not occurring using a Hoare triple as below: {x=0.1&&y=0}loop-body{y>=0}, which can be proved using the following loop invariant: y>=0.

Week 11: Exercise 2 Sample: y=1, orig(x) > 0, x > y, return = *x, return = orig(*x) + y

Week 11: Exercise 3 The same tree (the proof) will be built. L0 L1 L2 L3 new!=old L4 L5 new=old+1 L1 L6 L2 L5 L1 subsumed by new!=old

Week 12: Exercise 1

Week 12: Exercise 2 1: if (*) { 3: got_lock = 0; 4: if (*) { 5: lock(); 6: got_lock ++; 7: } 8: if (got_lock) { 9: unlock(); 10: } 11: if (*) {goto 3;} 12: } 14: lock(); 15: old = new; 16: if (*) { 17: unlock(); 18: new ++; 19: } 20: if (new != old) {goto 14;} 21: unlock (); 1: if (*) { 3: skip; 4: if (*) { 5: locked=true 6: skip; 7: } 8: if (*) { 9: locked=false; 10: } 11: if (*) {goto 3;} 12: } 14: locked=true; 15: skip; 16: if (*) { 17: locked=false; 18: skip; 19: } 20: if (*) {goto 14;} 21: locked=true;

Week 12: Exercise 3 r gy

Week 12: Exercise {!locked, ne} {locked, ne} {locked, !ne} {!locked, !ne} {!locked, ne} 8 {locked, !ne}