Runtime Checking and Test Case Generation for Python
|
|
- Nickolas Gregory
- 5 years ago
- Views:
Transcription
1 Runtime Checking and Test Case Generation for Python Anna Durrer Master Thesis Chair of Programming Methodology D-INFK ETH Supervisor: Marco Eilers, Prof. Peter Müller 24. Mai Introduction This thesis is part of a software verification project of the Chair of Programming Methodology. The goal of program verification is to prove mathematically that the given program fulfils a given formal specification. The consequence is that for every input that fulfils the precondition the postcondition and all loop invariants have to hold. This is more powerful than testing in that the results are guaranteed for any inputs. Writing all the necessary conditions, also called contracts, can be tedious and error-prone, therefore it is desirable to write them incrementally and check whether they are sufficient. One of the problems that occurs when writing contracts is that whenever the program cannot be verified by an automatic verifier, the cause could lie in three different reasons. The different kinds of errors are: The program code contains one or more errors that disallows the correct contracts to be proven. A specification is too weak. This means that a precondition or loop invariant within the method or a postcondition of a called method is not strong enough and has to be amended. The contracts are of a form that is not provable by the verifier. For example, the SMT solver cannot prove some non-linear arithmetic expressions. For a programmer, it is important to distinguish these errors, because then they know whether to change the code or specification. 1
2 In this thesis, we aim to develop an automated mechanism that uses a counterexample and the symbolic heap that we get from the verifier to decide whether the detected error is more likely in the specification or the code. 1.1 Example # Example for different kinds of error in Python def m (self, my_boolean): #Method with one argument, a boolean Ensures (self.x == 3) #Postcondition if my_boolean: #Branching self.x = 2 #Setting x to the wrong value => CODE ERROR else: calculate_x(self) #Calling a method => SPECIFICATION ERROR def calculate_x(self): Ensures (self.x > 0) self.x = 3 #Too weak postcondition #Correct code Here is an example of Python code with different kinds of verification errors. In the method m there are two errors: In Line 4, the program sets x to 2 but the specification states that x has to be 3 at the end of the execution. This is a program code error because the code does not comply with the required result. (Of course, it could be possible that the postcondition is wrong, but we assume that the postcondition of a method is always correct but maybe too weak for calling methods.) The postcondition of calculate x is not strong enough to actually prove that x is 3 at the end of the second branch. Here, it is a specification error, because the code guarantees our postcondition but calculate x does not guarantee it in its specification. 1.2 SCION As mentioned above, this thesis is part of a project of the Chair of Programming Methodology. The project is the verification of the Python implementation of the SCION internet architecture developed at ETH. The verification is done automatically by a newly developed static verifier called Nagini that has its own specification language. One speciality of Viper, which is used by Nagini, are the access permissions for each heap or field access. Each heap location has a total permission of 1, this means the sum of all permissions given is at most 1. To read or write a heap location a method needs to acquire a fraction of the total permission. Namely, to read an object, a positive fraction of a permission is needed (for example 0.5). To write to a heap location, we need the full permission of 1. 2
3 1.3 Counterexample The verifier represents a possible code or specification error by a counterexample. The counterexample given by the Symbolic Execution verifier of Viper consists of two different kinds of information. The counterexample of the Z3 prover - an SMT solver - with values assigned to variables and the symbolic state at every point in the execution. The symbolic state is - slightly simplified - structured in the following way: store #Local variables x Int x 0 y Ref y 0 z Ref z 0 heap #Known heap structure with permissions y 0.f 0.5 v 2 path_condition #Path conditions established at program point is_instance(x 0, list) v 2 > 0 Here, it is important to note that the symbolic state has incomplete information. Only fields that have permissions are visible in the state but there is no information about fields without permission. 1.4 Approach To solve the problem of distinguishing the different errors mentioned above, the goal is to use the counterexample as specified in the previous section. The steps that we will use are the following: 1. Run the static verifier and obtain a counterexample. 2. Generate test inputs that fulfil the conditions of the counterexample. 3. Run the test cases on the program and check all assertions and contracts at runtime. 2 Core Goals 2.1 Runtime Checking One part of this Master thesis deals with the problem of translating a Python method with specifications that are only checked in the verifier to a Python method that checks the properties also at runtime Determining strategy As the first step, it is necessary to determine which Viper pre-, postconditions and loop invariants can be translated where and how to Python assertions. Especially, the translation of the above described permissions seems to be challenging 3
4 because each heap access has to be checked for the correct permission. Another important part here is to decide which data structures are used for representing permissions, as those are just concepts within the verification language Implementation After determining how to translate the Viper contracts into Python assertions, the next step is the implementation of a code instrumentation that transforms any method into a method with the according assertions. Methodically, it is interesting how to transform Python programs that use methods of standard libraries. The interesting thing about standard libraries is that contracts have been written for their methods but the contracts are unchecked. It would be desirable to check at least some of the contracts also in standard libraries when doing runtime checking. One idea is to rewrite the method getattribute - that is called whenever a field is accessed in any Python method - for any type of Python to check whether the access is allowed according to the method s permissions, whether or not this approach is useful has to be determined at this step. 2.2 Test Case Generation Another important step in this thesis is to actually produce test cases that check which of the above mentioned error categories the error reported by the SMT solver actually belongs to Parsing counterexample The counterexample given by the SMT solver is quite difficult to read and understand. The first step for producing test cases is to parse the counterexample and map it to Python - directly or via an intermediate step through Viper. Here, one expected difficulty is that the symbolic heap is not complete as shown above Generate input As the next step, several - if possible - objects that fulfil the conditions of the counterexample are to be produced automatically. And with those objects, different inputs for the method have to be constructed. It is notable that some input objects could not occur in the symbolic heap and have to be guessed. Here, different approaches on how to initialize unspecified values have to be tested or decided on (choose randomly, establish corner cases,...) 2.3 Combination The first two parts of the thesis, runtime checking and test case generation, have to be combined in the end. The generated test cases should be run on the translated methods accordingly and the results are to be returned in a useful way. For example, one could output all test inputs with the results (no assertion 4
5 broken or the assertion that does not hold). One part of the thesis is to apply the process to some of the examples in SCION and determine whether the output is useful for the programmer or not. 3 Extension Goals There are some extensions to the thesis that could improve the project further. Some of the proposed extensions are: Including information from predicates and functions in the test case generation step: Without including information from predicates and functions, we have two options: either we disallow programs that contain those or we ignore the information given by them and therefore can have false positives. In the first case, this extension allows a wider application and in the second one we can avoid false positives. Extending runtime checking by obligations: Nagini contains obligations, namely for I/O contracts, loop termination and other conditions. By including those in the runtime checking the project could have a wider application by including also programs with obligations or be more precise by checking obligations as well. Determining the statement where the contracts are too weak: If the project determines that the error is due to insufficient contracts, it would be quite helpful for the programmer to know at which instruction the contracts are insufficient. To that end, the runtime checking might be adapted to run a method from a certain point in the method and check when the input produced in the earlier steps in not sufficient. To illustrate how this could be accomplished, we should consider the following example: # Example for finding position of specification error in Python def m (self, my_boolean) #Method with one argumnt, a boolean Ensures(x == 3) #Postcondition calculate_y(self) #other function of no consequence calculate_x(self) #Place of SPECIFICATION ERROR calculate_z(self) #other function of no consequence In this example, the specification error is in the second function call but we do not know that in advance. So, the goal is that we can generate test inputs from the symbolic state at the end of some instruction (for example after the first method call) and then check whether the assertion holds or whether there are allowed inputs in the symbolic state that lead to an assertion failure (in this example we could start after the second function call with a value x = 1 and get an assertion failure). One difficulty here is that we have to generate additional values for local variables. 5
Automatic Verification of Closures and Lambda-Functions in Python Master s Thesis Project Description
Automatic Verification of Closures and Lambda-Functions in Python Master s Thesis Project Description Benjamin Weber March 2017 Introduction Higher-order functions take other functions as parameters. Thus,
More informationStatic program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
More informationGeneralized Verification Support for Magic Wands
Generalized Verification Support for Magic Wands Bachelor s Thesis Nils Becker, nbecker@student.ethz.ch Supervisors: Malte Schwerhoff, malte.schwerhoff@inf.ethz.ch Alexander J. Summers, alexander.summers@inf.ethz.ch
More informationLecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationMASTER THESIS. Petr Hudeček. Soothsharp: A C#-to-Viper translator. Department of Distributed and Dependable Systems. Software and Data Engineering
MASTER THESIS Petr Hudeček Soothsharp: A C#-to-Viper translator Department of Distributed and Dependable Systems Supervisor of the master thesis: Study programme: Study branch: RNDr. Pavel Parízek Ph.D.
More informationVerified Secure Routing
Verified Secure Routing David Basin ETH Zurich EPFL, Summer Research Institute June 2017 Team Members Verification Team Information Security David Basin Tobias Klenze Ralf Sasse Christoph Sprenger Thilo
More informationLecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationTowards Customizability of a Symbolic-Execution-Based Program Verifier
Chair of Programming Methodology Department of Computer Science ETH Zürich Towards Customizability of a Symbolic-Execution-Based Program Verifier Bachelor s Thesis Robin Sierra supervised by Vytautas Astrauskas,
More informationPart II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
More informationProgram Verification using Templates over Predicate Abstraction. Saurabh Srivastava and Sumit Gulwani
Program Verification using Templates over Predicate Abstraction Saurabh Srivastava and Sumit Gulwani ArrayInit(Array A, int n) i := 0; while (i < n) A[i] := 0; i := i + 1; Assert( j: 0 j
More information6. Hoare Logic and Weakest Preconditions
6. Hoare Logic and Weakest Preconditions Program Verification ETH Zurich, Spring Semester 07 Alexander J. Summers 30 Program Correctness There are many notions of correctness properties for a given program
More informationSymbolic Execution and Proof of Properties
Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program
More informationViper A Verification Infrastructure for Permission-Based Reasoning
Viper A Verification Infrastructure for Permission-Based Reasoning Alex Summers, ETH Zurich Joint work with Uri Juhasz, Ioannis Kassios, Peter Müller, Milos Novacek, Malte Schwerhoff (and many students)
More informationBasic Verification Strategy
ormal Verification Basic Verification Strategy compare behavior to intent System Model of system behavior intent Verifier results Intent Usually, originates with requirements, refined through design and
More informationLecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
More informationCover Page. The handle holds various files of this Leiden University dissertation
Cover Page The handle http://hdl.handle.net/1887/22891 holds various files of this Leiden University dissertation Author: Gouw, Stijn de Title: Combining monitoring with run-time assertion checking Issue
More informationAXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
More informationCombining Static and Dynamic Contract Checking for Curry
Michael Hanus (CAU Kiel) Combining Static and Dynamic Contract Checking for Curry LOPSTR 2017 1 Combining Static and Dynamic Contract Checking for Curry Michael Hanus University of Kiel Programming Languages
More informationReferences: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationLecture 10 Design by Contract
CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components
More informationCSC Advanced Object Oriented Programming, Spring Specification
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Specification Specification A specification is an unambiguous description of the way the components of the software system should be used and
More informationSemantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics
There is no single widely acceptable notation or formalism for describing semantics Operational Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The
More informationAssertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationIntroduction to Axiomatic Semantics
Introduction to Axiomatic Semantics Meeting 10, CSCI 5535, Spring 2009 Announcements Homework 3 due tonight Homework 2 is graded 13 (mean), 14 (median), out of 21 total, but Graduate class: final project
More informationHoare Logic: Proving Programs Correct
Hoare Logic: Proving Programs Correct 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich Reading: C.A.R. Hoare, An Axiomatic Basis for Computer Programming Some presentation ideas from a lecture
More informationWarm-Up Problem. 1. What is the definition of a Hoare triple satisfying partial correctness? 2. Recall the rule for assignment: x (assignment)
Warm-Up Problem 1 What is the definition of a Hoare triple satisfying partial correctness? 2 Recall the rule for assignment: x (assignment) Why is this the correct rule and not the following rule? x (assignment)
More informationLecture Notes: Hoare Logic
Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for
More informationn Specifying what each method does q Specify it in a comment before method's header n Precondition q Caller obligation n Postcondition
Programming as a contract Assertions, pre/postconditions and invariants Assertions: Section 4.2 in Savitch (p. 239) Loop invariants: Section 4.5 in Rosen Specifying what each method does q Specify it in
More informationTesting, Debugging, and Verification
Testing, Debugging, and Verification Formal Specification, Part II Srinivas Pinisetty 23 November 2017 Introduction Today: Introduction to Dafny: An imperative language with integrated support for formal
More informationGoal. Overflow Checking in Firefox. Sixgill. Sixgill (cont) Verifier Design Questions. Sixgill: Properties 4/8/2010
Goal Overflow Checking in Firefox Brian Hackett Can we clean a code base of buffer overflows? Keep it clean? Must prove buffer accesses are in bounds Verification: prove a code base has a property Sixgill
More informationLecture Notes on Memory Layout
Lecture Notes on Memory Layout 15-122: Principles of Imperative Computation Frank Pfenning André Platzer Lecture 11 1 Introduction In order to understand how programs work, we can consider the functions,
More informationChapter 3 (part 3) Describing Syntax and Semantics
Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings
More informationAssertions & Design-by-Contract using JML Erik Poll University of Nijmegen
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Erik Poll - JML p.1/39 Overview Assertions Design-by-Contract for Java using JML Contracts and Inheritance Tools for JML Demo
More informationSpark verification features
Spark verification features Paul Jackson School of Informatics University of Edinburgh Formal Verification Spring 2018 Adding specification information to programs Verification concerns checking whether
More informationLectures 20, 21: Axiomatic Semantics
Lectures 20, 21: Axiomatic Semantics Polyvios Pratikakis Computer Science Department, University of Crete Type Systems and Static Analysis Based on slides by George Necula Pratikakis (CSD) Axiomatic Semantics
More informationVerification Condition Generation for Magic Wands
Chair of Programming Methodology Department of Computer Science ETH Zurich Verification Condition Generation for Magic Wands Bachelor s Thesis Author: Gaurav Parthasarathy gauravp@student.ethz.ch Supervised
More informationProgram Verification (6EC version only)
Program Verification (6EC version only) Erik Poll Digital Security Radboud University Nijmegen Overview Program Verification using Verification Condition Generators JML a formal specification language
More informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Describing the Meanings of Programs: Dynamic Semantics Copyright 2015 Pearson. All rights reserved. 2 Semantics There is no
More informationSoftware Development. Modular Design and Algorithm Analysis
Software Development Modular Design and Algorithm Analysis Precondition and Postcondition To create a good algorithm, a programmer must be able to analyse a precondition (starting state) and a postcondition
More informationAssertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What
More informationGeneralised Verification for Quantified Permissions
Generalised Verification for Quantified Permissions Master Thesis Nadja Müller Supervised by Alexander Summers, Prof. Dr. Peter Müller Department of Computer Science ETH Zurich September 29, 2016 Contents
More informationCMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics
Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End
More informationLecture Notes on Linear Search
Lecture Notes on Linear Search 15-122: Principles of Imperative Computation Frank Pfenning Lecture 5 January 28, 2014 1 Introduction One of the fundamental and recurring problems in computer science is
More informationLecture 18 Restoring Invariants
Lecture 18 Restoring Invariants 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In this lecture we will implement heaps and operations on them. The theme of this lecture is reasoning
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationHardware versus software
Logic 1 Hardware versus software 2 In hardware such as chip design or architecture, designs are usually proven to be correct using proof tools In software, a program is very rarely proved correct Why?
More informationSoftware Engineering Testing and Debugging Testing
Software Engineering Testing and Debugging Testing Prof. Dr. Peter Thiemann Universitt Freiburg 08.06.2011 Recap Testing detect the presence of bugs by observing failures Debugging find the bug causing
More informationResearch Collection. Overapproximating the Cost of Loops. Master Thesis. ETH Library. Author(s): Schweizer, Daniel. Publication Date: 2013
Research Collection Master Thesis Overapproximating the Cost of Loops Author(s): Schweizer, Daniel Publication Date: 2013 Permanent Link: https://doi.org/10.3929/ethz-a-009767769 Rights / License: In Copyright
More informationVS 3 : SMT Solvers for Program Verification
VS 3 : SMT Solvers for Program Verification Saurabh Srivastava 1,, Sumit Gulwani 2, and Jeffrey S. Foster 1 1 University of Maryland, College Park, {saurabhs,jfoster}@cs.umd.edu 2 Microsoft Research, Redmond,
More informationTranslating Scala to SIL
Translating Scala to SIL Master s Thesis Bernhard F. Brodowsky June 17, 2013 Advisors: Prof. Dr. P. Müller, M. Schwerhoff Department of Computer Science, ETH Zürich Abstract In this thesis, we describe
More informationHoare Logic and Model Checking
Hoare Logic and Model Checking Kasper Svendsen University of Cambridge CST Part II 2016/17 Acknowledgement: slides heavily based on previous versions by Mike Gordon and Alan Mycroft Introduction In the
More informationJML tool-supported specification for Java Erik Poll Radboud University Nijmegen
JML tool-supported specification for Java Erik Poll Radboud University Nijmegen Erik Poll - JML p.1/41 Overview The specification language JML Tools for JML, in particular runtime assertion checking using
More informationCSC313 High Integrity Systems/CSCM13 Critical Systems. CSC313/CSCM13 Chapter 2 1/ 221
CSC313 High Integrity Systems/CSCM13 Critical Systems CSC313/CSCM13 Chapter 2 1/ 221 CSC313 High Integrity Systems/ CSCM13 Critical Systems Course Notes Chapter 2: SPARK Ada Sect. 2 (f) Anton Setzer Dept.
More informationAdvances in Programming Languages
T O Y H Advances in Programming Languages APL4: JML The Java Modeling Language David Aspinall (slides originally by Ian Stark) School of Informatics The University of Edinburgh Thursday 21 January 2010
More informationThe Boogie Intermediate Language
The Boogie Intermediate Language What is BoogiePL? A simplified C-like language that s structured for verification tasks Has constructs that allow specification of assumptions and axioms, as well as assertions
More informationMain Goal. Language-independent program verification framework. Derive program properties from operational semantics
Main Goal Language-independent program verification framework Derive program properties from operational semantics Questions: Is it possible? Is it practical? Answers: Sound and complete proof system,
More informationHoare Logic and Model Checking. A proof system for Separation logic. Introduction. Separation Logic
Introduction Hoare Logic and Model Checking In the previous lecture we saw the informal concepts that Separation Logic is based on. Kasper Svendsen University of Cambridge CST Part II 2016/17 This lecture
More informationAn Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
More informationIncremental Proof Development in Dafny
15-414 Lecture 17 1 Instructor: Matt Fredrikson Incremental Proof Development in Dafny TA: Ryan Wagner In this discussion, we ll see in more detail how to go about proving the total correctness of imperative
More informationAn Introduction to Heap Analysis. Pietro Ferrara. Chair of Programming Methodology ETH Zurich, Switzerland
An Introduction to Heap Analysis Pietro Ferrara Chair of Programming Methodology ETH Zurich, Switzerland Analisi e Verifica di Programmi Universita Ca Foscari, Venice, Italy Outline 1. Recall of numerical
More informationAvoiding undefined behavior in contracts
Document Number: P1290R0 Date: 2018-11-26 Reply to: J. Daniel Garcia e-mail: josedaniel.garcia@uc3m.es Audience: EWG Avoiding undefined behavior in contracts J. Daniel Garcia Computer Science and Engineering
More informationStatic verification of program running time
Static verification of program running time CIS 673 course project report Caleb Stanford December 2016 Contents 1 Introduction 2 1.1 Total Correctness is Not Enough.................................. 2
More informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationThe JML Tool. Faculty of Engineering Pontificia Universidad Javeriana. The JML Tool p.1/23
The JML Tool Néstor Cataño ncatano@puj.edu.co Faculty of Engineering Pontificia Universidad Javeriana The JML Tool p.1/23 Tools for JML 1. Parsing and type-checking 2. Checking assertions at runtime 3.
More informationTool Support for Design Inspection: Automatic Generation of Questions
Tool Support for Design Inspection: Automatic Generation of Questions Tim Heyer Department of Computer and Information Science, Linköping University, S-581 83 Linköping, Email: Tim.Heyer@ida.liu.se Contents
More informationDeductive Verification in Frama-C and SPARK2014: Past, Present and Future
Deductive Verification in Frama-C and SPARK2014: Past, Present and Future Claude Marché (Inria & Université Paris-Saclay) OSIS, Frama-C & SPARK day, May 30th, 2017 1 / 31 Outline Why this joint Frama-C
More informationProgram Verification. Aarti Gupta
Program Verification Aarti Gupta 1 Agenda Famous bugs Common bugs Testing (from lecture 6) Reasoning about programs Techniques for program verification 2 Famous Bugs The first bug: A moth in a relay (1945)
More informationFormal Specification and Verification
Formal Specification and Verification Formal Specification, Part III Bernhard Beckert Adaptation of slides by Wolfgang Ahrendt Chalmers University, Gothenburg, Sweden Formal Specification and Verification:
More informationCounterexample-Driven Genetic Programming
Counterexample-Driven Genetic Programming Iwo Błądek, Krzysztof Krawiec Institute of Computing Science, Poznań University of Technology Poznań, 12.12.2017 I. Błądek, K. Krawiec Counterexample-Driven Genetic
More informationIntegrating dynamic test generation with sound verification. Patrick Emmisberger
Integrating dynamic test generation with sound verification Patrick Emmisberger Research in Computer Science Chair of Programming Methodology Department of Computer Science ETH Zurich http://www.pm.inf.ethz.ch/
More informationProving well-formedness of interface specifications. Geraldine von Roten
Proving well-formedness of interface specifications Geraldine von Roten Master Project Report Software Component Technology Group Department of Computer Science ETH Zurich http://sct.inf.ethz.ch/ Fall/2007
More informationHoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré
Hoare Logic COMP2600 Formal Methods for Software Engineering Rajeev Goré Australian National University Semester 2, 2016 (Slides courtesy of Ranald Clouston) COMP 2600 Hoare Logic 1 Australian Capital
More informationAutomatic Generation of Program Specifications
Automatic Generation of Program Specifications Jeremy Nimmer MIT Lab for Computer Science http://pag.lcs.mit.edu/ Joint work with Michael Ernst Jeremy Nimmer, page 1 Synopsis Specifications are useful
More informationCS 220: Discrete Structures and their Applications. Loop Invariants Chapter 3 in zybooks
CS 220: Discrete Structures and their Applications Loop Invariants Chapter 3 in zybooks Program verification How do we know our program works correctly? In this lecture we will focus on a tool for verifying
More informationInvariant Based Programming
Invariant Based Programming Ralph-Johan Back Abo Akademi and TUCS June 2006 Constructing correct programs: alternative approaches A posteriori correctness proof (Floyd, Naur, Hoare,...). Prove correctness
More informationObject Ownership in Program Verification
Object Ownership in Program Verification Werner Dietl 1 and Peter Müller 2 1 University of Washington wmdietl@cs.washington.edu 2 ETH Zurich peter.mueller@inf.ethz.ch Abstract. Dealing with aliasing is
More informationIII. Check if the divisors add up to the number. Now we may consider each of these tasks separately, assuming the others will be taken care of
Top-Down Design 1 Top-Down Design: A solution method where the problem is broken down into smaller sub-problems, which in turn are broken down into smaller subproblems, continuing until each sub-problem
More informationRepetition Through Recursion
Fundamentals of Computer Science I (CS151.02 2007S) Repetition Through Recursion Summary: In many algorithms, you want to do things again and again and again. For example, you might want to do something
More informationThe Contract Pattern. Design by contract
The Contract Pattern Copyright 1997, Michel de Champlain Permission granted to copy for PLoP 97 Conference. All other rights reserved. Michel de Champlain Department of Computer Science University of Canterbury,
More informationSemantic Analysis. CSE 307 Principles of Programming Languages Stony Brook University
Semantic Analysis CSE 307 Principles of Programming Languages Stony Brook University http://www.cs.stonybrook.edu/~cse307 1 Role of Semantic Analysis Syntax vs. Semantics: syntax concerns the form of a
More informationSoftware Engineering
Software Engineering Lecture 13: Testing and Debugging Testing Peter Thiemann University of Freiburg, Germany SS 2014 Recap Recap Testing detect the presence of bugs by observing failures Recap Testing
More informationVerifying JML specifications with model fields
Verifying JML specifications with model fields Cees-Bart Breunesse and Erik Poll Department of Computer Science, University of Nijmegen Abstract. The specification language JML (Java Modeling Language)
More informationAvoiding undefined behavior in contracts
Document Number: P1290R1 Date: 2019-01-21 Reply to: J. Daniel Garcia e-mail: josedaniel.garcia@uc3m.es Audience: EWG / CWG Avoiding undefined behavior in contracts J. Daniel Garcia Computer Science and
More informationOutline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include
Outline Computer Science 331 Correctness of Algorithms Mike Jacobson Department of Computer Science University of Calgary Lectures #2-4 1 What is a? Applications 2 Recursive Algorithms 3 Final Notes Additional
More informationMidterm I Exam Principles of Imperative Computation André Platzer Ananda Gunawardena. February 23, 2012
Midterm I Exam 15-122 Principles of Imperative Computation André Platzer Ananda Gunawardena February 23, 2012 Name: Sample Solution Andrew ID: aplatzer Section: Instructions This exam is closed-book with
More informationImplementation of frozen objects into Spec#
Research Collection Master Thesis Implementation of frozen objects into Spec# Author(s): Leu, Florian Publication Date: 2009 Permanent Link: https://doi.org/10.3929/ethz-a-005899162 Rights / License: In
More informationGNATprove a Spark2014 verifying compiler Florian Schanda, Altran UK
1 GNATprove a Spark2014 verifying compiler Florian Schanda, Altran UK Tool architecture User view Source gnatprove Verdict 2 Tool architecture More detailed view... Source Encoding CVC4 gnat2why gnatwhy3
More informationSpecifications. Prof. Clarkson Fall Today s music: Nice to know you by Incubus
Specifications Prof. Clarkson Fall 2015 Today s music: Nice to know you by Incubus Question Would you like a tiny bonus to your final grade for being here on time today? A. Yes B. Sí C. Hai D. Haan E.
More informationDM502 Programming A. Peter Schneider-Kamp.
DM502 Programming A Peter Schneider-Kamp petersk@imada.sdu.dk! http://imada.sdu.dk/~petersk/dm502/! Python & Linux Install Party Tomorrow (Tuesday, September 12) from 10 14 Fredagsbar (area south of Kantine
More informationChecking Program Properties with ESC/Java
Checking Program Properties with ESC/Java 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich 1 ESC/Java A checker for Java programs Finds null pointers, array dereferences Checks Hoare logic
More informationESC/Java2 vs. JMLForge. Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany
ESC/Java2 vs. JMLForge Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany ESC/Java2: the formula is built using Dijsktra s Weakes precondition. Automatic theorem prover: Simplify
More informationFreePascal changes: user documentation
FreePascal changes: user documentation Table of Contents Jochem Berndsen February 2007 1Introduction...1 2Accepted syntax...2 Declarations...2 Statements...3 Class invariants...3 3Semantics...3 Definitions,
More informationProof Carrying Code(PCC)
Discussion p./6 Proof Carrying Code(PCC Languaged based security policy instead of OS-based A mechanism to determine with certainity that it is safe execute a program or not Generic architecture for providing
More informationOutline. software testing: search bugs black-box and white-box testing static and dynamic testing
Outline 1 Verification Techniques software testing: search bugs black-box and white-box testing static and dynamic testing 2 Programming by Contract assert statements in Python using preconditions and
More informationIntroduction to Axiomatic Semantics (1/2)
#1 Introduction to Axiomatic Semantics (1/2) How s The Homework Going? Remember: just do the counterexample guided abstraction refinement part of DPLL(T). If you notice any other errors, those are good
More informationESC/Java 2. Checker for Java 2. Extended. Static. B y K ats man Andrey S oftware E ngineering S em inar
ESC/Java 2 Extended Static Checker for Java 2 B y K ats man Andrey S oftware E ngineering S em inar 2 0 0 8 Background ESC/Java - Original development by Compaq Systems Research Center (1997) as a successor
More informationLanguage Techniques for Provably Safe Mobile Code
Language Techniques for Provably Safe Mobile Code Frank Pfenning Carnegie Mellon University Distinguished Lecture Series Computing and Information Sciences Kansas State University October 27, 2000 Acknowledgments:
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationVerification Condition Generation
Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture
More information