Static Program Analysis

Similar documents
Static Program Analysis

Static Program Analysis

Semantics and Verification of Software

Semantics and Verification of Software

Static Program Analysis

Static Program Analysis

Static Program Analysis

Program Analysis. Lecture 5. Rayna Dimitrova WS 2016/2017

Abstract Interpretation: Fixpoints, widening, and narrowing

Principles of Program Analysis: Control Flow Analysis

Abstract Interpretation: Fixpoints, widening, and narrowing

Principles of Program Analysis: Abstract Interpretation

Probabilistic Model Checking and [Program] Analysis (CO469)

Introduction to Abstract Interpretation. ECE 584 Sayan Mitra Lecture 18

Nachklausur zur Vorlesung Vertiefung Theoretische Informatik Wintersemester

Static Program Analysis using Abstract Interpretation

The algorithmic analysis of hybrid system

Model Checking & Program Analysis

Abstract Interpretation II

Klausur zur Vorlesung Vertiefung Theoretische Informatik Sommersemester 2016

MIT Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology

Probabilistic Program Analysis

1. Einleitung. 1.1 Organisatorisches. Ziel der Vorlesung: Einführung in die Methoden der Ökonometrie. Voraussetzungen: Deskriptive Statistik

Reading: Chapter 9.3. Carnegie Mellon

Static Program Analysis

Discrete Fixpoint Approximation Methods in Program Static Analysis

Answers to the CSCE 551 Final Exam, April 30, 2008

Hoare Calculus and Predicate Transformers

Mechanics of Static Analysis

Dataflow Analysis. Chapter 9, Section 9.2, 9.3, 9.4

Formal Methods in Software Engineering

Computational Models: Class 3

Klausur zur Vorlesung Vertiefung Theoretische Informatik Sommersemester

Dataflow Analysis - 2. Monotone Dataflow Frameworks

Foundations of Informatics: a Bridging Course

Verification of Real-Time Systems Numerical Abstractions

Scalar Optimisation Part 2

Principles of Program Analysis: Data Flow Analysis

Advanced Automata Theory 11 Regular Languages and Learning Theory

CMSC 631 Program Analysis and Understanding. Spring Data Flow Analysis

Principles of Program Analysis: A Sampler of Approaches

0.1 Random useful facts. 0.2 Language Definition

Algorithmic verification

Dataflow analysis. Theory and Applications. cs6463 1

Goal. Partially-ordered set. Game plan 2/2/2013. Solving fixpoint equations

Program Analysis Probably Counts

Lecture 4. Finite Automata and Safe State Machines (SSM) Daniel Kästner AbsInt GmbH 2012

What we have done so far

Compiler Construction

Smoothing a Program Soundly and Robustly

Compilers. Lexical analysis. Yannis Smaragdakis, U. Athens (original slides by Sam

Advanced Automata Theory 2 Finite Automata

Decision Procedures. Jochen Hoenicke. Software Engineering Albert-Ludwigs-University Freiburg. Winter Term 2016/17

Lecture Notes: Program Analysis Correctness

4.3 Composition Series

CSC D70: Compiler Optimization Dataflow-2 and Loops

Gerwin Klein, June Andronick, Ramana Kumar S2/2016

Denotational semantics

Data flow analysis. DataFlow analysis

Introduction to Program Analysis and Abstract Interpretation (Part I)

DFA of non-distributive properties

COMP-330 Theory of Computation. Fall Prof. Claude Crépeau. Lec. 5 : DFA minimization

Verification of String Manipulating Programs Using Multi-Track Automata

Axiomatic Semantics: Verification Conditions. Review of Soundness and Completeness of Axiomatic Semantics. Announcements

Theory of Computation 3 Deterministic Finite Automata

Topic-I-C Dataflow Analysis

Deterministic Finite Automata

CSE 105 Theory of Computation

Chapter 6 Constraint Satisfaction Problems

Übung Informatik I - Programmierung - Blatt 7

Software Verification

Topics in Model-Based Reasoning

CS 6110 S16 Lecture 33 Testing Equirecursive Equality 27 April 2016

V Honors Theory of Computation

The theory of regular cost functions.

Hoare Logic: Reasoning About Imperative Programs

(a) Definition of TMs. First Problem of URMs

Computational Models - Lecture 3

COMP-330 Theory of Computation. Fall Prof. Claude Crépeau. Lec. 9 : Myhill-Nerode Theorem and applications

Design of Distributed Systems Melinda Tóth, Zoltán Horváth

«ATutorialon Abstract Interpretation»

Compilation and Program Analysis (#8) : Abstract Interpretation

TWO-WAY FINITE AUTOMATA & PEBBLE AUTOMATA. Written by Liat Peterfreund

G54FOP: Lecture 17 & 18 Denotational Semantics and Domain Theory III & IV

Bayesian D-optimal Design

Theoretical Foundations of the UML

Deterministic Finite Automata

International Steam Tables - Properties of Water and Steam based on

CMSC 631 Program Analysis and Understanding Fall Abstract Interpretation

Automata-Theoretic Model Checking of Reactive Systems

Data Flow Analysis. Lecture 6 ECS 240. ECS 240 Data Flow Analysis 1

Precise Program Analysis through (Linear) Algebra

A Certified Denotational Abstract Interpreter (Proof Pearl)

Classes of Boolean Functions

Static Program Analysis. Seidl/Wilhelm/Hack: Compiler Design Analysis and Transformation, Springer Verlag, 2012

First-Order Theorem Proving and Vampire. Laura Kovács (Chalmers University of Technology) Andrei Voronkov (The University of Manchester)

Review. Principles of Programming Languages. Equality. The Diamond Property. The Church-Rosser Theorem. Corollaries. CSE 230: Winter 2007

Automatic Verification of Parameterized Data Structures

Formal Techniques for Software Engineering: Denotational Semantics

Spring 2016 Program Analysis and Verification. Lecture 3: Axiomatic Semantics I. Roman Manevich Ben-Gurion University

Transcription:

Static Program Analysis Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ws-1617/spa/

Software Architektur Praxis-Workshop Bringen Sie Informatik zur Wirkung! Serviceorientiert, zustandslos, geschichtet, lose gekoppelt, ad hoc entstanden oder model-driven was ist die beste Softwarearchitektur? Inhalte des Workshops: Anhand eines realen Beispiels aus der Praxis entwickelt ihr in kleinen Teams die Architektur für ein Informationssystem. Da sich Software fortlaufend weiterentwickelt, prüfen wir, wie sich die Architektur gegenüber neuen, auch unerwarteten Anforderungen verhält und daran anpassen lässt. Gemeinsam diskutieren wir den Einfluss verschiedener Anforderungen, mögliche Varianten und ihre Auswirkungen. Außerdem zeigen wir euch die Aufgaben eines Softwarearchitekten und wie er Projekte zum Erfolg führt. Mittwoch, 14.12.2016, 09.00-16.00 Uhr Seminarraum 5053.2, B-IT Research School, RWTH Aachen (Ahornstraße 55) Melden Sie sich unter Angabe Ihres Semesters bis zum 4.12.2016 an. Wir freuen uns auf Sie! Kontakt: Anne-Kristin Hauk (hauk@itestra.de) www.itestra.com 2016 itestra GmbH www.itestra.de

Recap: The MOP Solution The MOP Solution Definition (MOP solution) Let S = (Lab, E, F, (D, ), ι, ϕ) be a dataflow system where Lab = {l 1,..., l n }. The MOP solution for S is determined by where, for every l Lab, mop(s) := (mop(l 1 ),..., mop(l n )) D n mop(l) := {ϕ π (ι) π Path(l)}. Remark: Path(l) is generally infinite not clear how to compute mop(l) In fact: MOP solution generally undecidable (later) 4 of 27 Static Program Analysis

Recap: The MOP Solution MOP vs. Fixpoint Solution I Example (Constant Propagation) c := if [z > 0] 1 then [x := 2] 2 ; [y := 3] 3 else [x := 3] 4 ; [y := 2] 5 end; [z := x+y] 6 ; [...] 7 Transfer functions (for δ = (δ(x), δ(y), δ(z)) D): ϕ 1 (a, b, c) = (a, b, c) ϕ 2 (a, b, c) = (2, b, c) ϕ 3 (a, b, c) = (a, 3, c) ϕ 4 (a, b, c) = (3, b, c) ϕ 5 (a, b, c) = (a, 2, c) ϕ 6 (a, b, c) = (a, b, a + b) 1. Fixpoint solution: CP 1 = ι = (,, ) CP 2 = ϕ 1 (CP 1 ) = (,, ) CP 3 = ϕ 2 (CP 2 ) = (2,, ) CP 4 = ϕ 1 (CP 1 ) = (,, ) CP 5 = ϕ 4 (CP 4 ) = (3,, ) CP 6 = ϕ 3 (CP 3 ) ϕ 5 (CP 5 ) = (2, 3, ) (3, 2, ) = (,, ) CP 7 = ϕ 6 (CP 6 ) = (,, ) 2. MOP solution: mop(7) = ϕ [1,2,3,6] (,, ) ϕ [1,4,5,6] (,, ) = (2, 3, 5) (3, 2, 5) = (,, 5) 5 of 27 Static Program Analysis

Recap: The MOP Solution MOP vs. Fixpoint Solution II Theorem (MOP vs. Fixpoint Solution) Let S = (Lab, E, F, (D, ), ι, ϕ) be a dataflow system. Then Reminder: by Definition 4.9, mop(s) fix(φ S ) Φ S : D n D n : (d 1,..., d n ) (d 1,..., d n) where Lab = {1,..., n} and, for each l Lab, Proof. on the board d l := { ι if l E {ϕl (d l ) (l, l) F} otherwise Remark: as Example?? shows, mop(s) fix(φ S ) is possible 6 of 27 Static Program Analysis

Recap: The MOP Solution Distributivity of Transfer Functions A sufficient condition for the coincidence of MOP and Fixpoint Solution is the distributivity of the transfer functions. Definition (Distributivity) Let (D, ) and (D, ) be complete lattices. Function F : D D is called distributive (w.r.t. (D, ) and (D, )) if, for every d 1, d 2 D, F(d 1 D d 2 ) = F(d 1 ) D F(d 2 ). A dataflow system S = (Lab, E, F, (D, ), ι, ϕ) is called distributive if every ϕ l : D D (l Lab) is so. 7 of 27 Static Program Analysis

Recap: The MOP Solution Coincidence of MOP and Fixpoint Solution Theorem (MOP vs. Fixpoint Solution) Let S = (Lab, E, F, (D, ), ι, ϕ) be a distributive dataflow system. Then mop(s) = fix(φ S ) Proof. mop(s) fix(φ S ): Theorem?? fix(φ S ) mop(s): as fix(φ S ) is the least fixpoint of Φ S, it suffices to show that Φ S (mop(s)) = mop(s) (on the board) 8 of 27 Static Program Analysis

Undecidability of the MOP Solution Undecidability of the MOP Solution I Theorem 7.1 (Undecidability of MOP solution) The MOP solution for Constant Propagation is undecidable. Proof. Based on undecidability of Modified Post Correspondence Problem: Let Γ be some alphabet, n N, and u 1,..., u n, v 1,..., v n Γ +. Do there exist i 1,..., i m {1,..., n} with m 1 and i 1 = 1 such that u i1 u i2... u im = v i1 v i2... v im? Given a MPCP, we construct a WHILE program (with strings and Booleans) whose MOP analysis detects a constant property iff the MPCP has no solution (see next slide). 10 of 27 Static Program Analysis

Undecidability of the MOP Solution Undecidability of the MOP Solution II Proof (continued). x := u 1 ;y := v 1 ; while... do if... then x := x ++ u 1 ; y := y ++ v 1 else if... then. else x := x ++ u n ; y := y ++ v n end... end end; z := (x = y); [skip] l Then: mop(l)(z) = false x y at the end of every path to l the MPCP has no solution 11 of 27 Static Program Analysis

Dataflow Analysis with Non-ACC Domains Dataflow Analysis with Non-ACC Domains Reminder: (D, ) satisfies ACC if each ascending chain d 0 d 1... eventually stabilises, i.e., there exists n N such that d n = d n+1 =... If height (= maximal chain size - 1) of (D, ) is m, then fixpoint computation terminates after at most Lab m iterations But: if (D, ) has non-stabilising ascending chains = algorithm may not terminate Solution: use widening operators to enforce termination 13 of 27 Static Program Analysis

Example: Interval Analysis Example: Interval Analysis Interval Analysis The goal of Interval Analysis is to determine, for each (interesting) program point, a safe interval for the values of the (interesting) program variables. Interval analysis is actually a generalisation of constant propagation ( interval analysis with 1-element intervals) Example 7.2 (Interval Analysis) var a[100]: int; i := 0; while i <= 42 do if i >= 0 i < 100 then a[i] := i end; i := i + 1; end; = redundant array bounds check 15 of 27 Static Program Analysis

Example: Interval Analysis The Domain of Interval Analysis The domain (Int, ) of intervals over Z is defined by Int := {[z 1, z 2 ] z 1 Z { }, z 2 Z {+ }}, z 1 z 2 } { } where z and z + (for all z Z) J (for all J Int) [y 1, y 2 ] [z 1, z 2 ] iff y 1 z 1 and y 2 z 2 (Int, ) is a complete lattice with (for every I Int) { if I = or I = { } I = [Z 1, Z 2 ] otherwise where Z 1 := Z { } {z 1 [z 1, z 2 ] I} Z 2 := Z {+ } {z 2 [z 1, z 2 ] I} (and thus =, = [, + ]) Clearly (Int, ) has infinite ascending chains, such as [1, 1] [1, 2] [1, 3]... 16 of 27 Static Program Analysis

Example: Interval Analysis The Complete Lattice of Interval Analysis [, + ] [, 1] [, 0] [, 1] [ 2, 2] [ 2, 1] [ 1, 2] [ 1, + ] [0, + ] [1, + ] 17 of 27 Static Program Analysis [ 2, 0] [ 1, 1] [0, 2] [ 2, 1] [ 1, 0] [0, 1] [1, 2] [ 2, 2] [ 1, 1] [0, 0] [1, 1] [2, 2]

Formalising Interval Analysis Formalising Interval Analysis I The dataflow system S = (Lab, E, F, (D, ), ι, ϕ) is given by set of labels Lab := Lab c extremal labels E := {init(c)} (forward problem) flow relation F := flow(c) (forward problem) complete lattice (D, ) where D := {δ δ : Var c Int} δ 1 δ 2 iff δ 1 (x) δ 2 (x) for every x Var c ι := D : Var c Int : x Int (with Int = [, + ]) ϕ: see next slide 19 of 27 Static Program Analysis

Formalising Interval Analysis Formalising Interval Analysis II Transfer functions {ϕ l l Lab} are defined by { δ if B l = skip or B ϕ l (δ) := l BExp δ[x val δ (a)] if B l = (x := a) where with val δ (x) := δ(x) val δ (z) := [z, z] val δ (a 1 +a 2 ) := val δ (a 1 ) val δ (a 2 ) val δ (a 1 -a 2 ) := val δ (a 1 ) val δ (a 2 ) val δ (a 1 *a 2 ) := val δ (a 1 ) val δ (a 2 ) J := J := J :=... := [y 1, y 2 ] [z 1, z 2 ] := [y 1 + z 1, y 2 + z 2 ] [y 1, y 2 ] [z 1, z 2 ] := [y 1 z 2, y 2 z 1 ] [y 1, y 2 ] [z 1, z 2 ] := [ {y 1 z 1, y 1 z 2, y 2 z 1, y 2 z 2 }, {y 1 z 1, y 1 z 2, y 2 z 1, y 2 z 2 }] 20 of 27 Static Program Analysis

Formalising Interval Analysis Remarks Possible refinement of DFA to take conditional blocks b l (b BExp) into account essentially: b as edge label, ϕ l (δ)(x) = δ(x) \ {z Z x = z = b} (cf. DFA with Conditional Branches later) Important: soundness and optimality of abstract operations, e.g., : soundness: z 1 J 1, z 2 J 2 = z 1 + z 2 J 1 J 2 optimality: J 1 J 2 as precise (i.e., small) as possible 21 of 27 Static Program Analysis

Formalising Interval Analysis Interval Analysis without Widening Example 7.3 [x := 1] 1 while [...] 2 [x := x + 1] 3 Transfer functions (for δ(x) = J): ϕ 1 (J) = [1, 1] ϕ 2 (J) = J ϕ 3 ( ) = ϕ 3 ([x 1, x 2 ]) = [x 1 + 1, x 2 + 1] Application of worklist algorithm without widening: does not terminate (on the board) 22 of 27 Static Program Analysis

Applying Widening to Interval Analysis Widening Operators Definition 7.4 (Widening operator) Let (D, ) be a complete lattice. A mapping : D D D is called widening operator if for every d 1, d 2 D, d 1 d 2 d 1 d 2 and for all ascending chains d 0 d 1..., the ascending chain d 0 d 1... eventually stabilises where d 0 := d 0 and d i+1 := d i d i+1 for each i N Remarks: (d i ) i N is clearly an ascending chain as d i+1 = d i d i+1 d i d i+1 d i In contrast to, does not have to be commutative, associative, monotonic, nor absorptive (d d = d) The requirement d 1 d 2 d 1 d 2 guarantees soundness of widening 24 of 27 Static Program Analysis

Applying Widening to Interval Analysis Applying Widening to Interval Analysis A widening operator: : Int Int Int with J := J := J [x 1, x 2 ] [y 1, y 2 ] := [z { 1, z 2 ] where x1 if x 1 y 1 z 1 := z 2 := { otherwise x2 if x 2 y 2 + otherwise Widening turns infinite ascending chain J 0 = J 1 = [1, 1] J 2 = [1, 2] J 3 = [1, 3]... into a finite one: J 0 = J 0 = J 1 = J 0 J 1 = [1, 1] = [1, 1] = J 1 J 2 = [1, 1] [1, 2] = [1, + ] J 2 J 3 = J 2 J 3 = [1, + ] [1, 3] = [1, + ] In fact, the maximal chain size arising with this operator is 4: [3, 7] [3, + ] [, + ] 25 of 27 Static Program Analysis

Applying Widening to Interval Analysis Worklist Algorithm with Widening I Goal: extend Algorithm 5.1 by widening to ensure termination Algorithm 7.5 (Worklist algorithm with widening) Input: dataflow system S = (Lab, E, F, (D, ), ι, ϕ) Variables: W (Lab Lab), {AI l D l Lab} Procedure: W := ε; for (l, l ) F do W := W (l, l ); % Initialise W for l Lab do if l E then AI l := ι else AI l := D ; % Initialise AI while W ε do (l, l ) := head(w); W := tail(w); % Next control-flow edge if ϕ l (AI l ) AI l then % Fixpoint not yet reached AI l := AI l ϕ l (AI l ); % Update analysis information for (l, l ) F do if (l, l ) not in W then W := (l, l ) W; % Propagate modification Output: {AI l l Lab}, denoted by fix (Φ S ) Remark: due to widening, only fix (Φ S ) fix(φ S ) is guaranteed (cf. Thm. 5.4) 26 of 27 Static Program Analysis

Applying Widening to Interval Analysis Worklist Algorithm with Widening II Example 7.6 [x := 1] 1 while [...] 2 [x := x + 1] 3 Transfer functions (for δ(x) = J): ϕ 1 (J) = [1, 1] ϕ 2 (J) = J ϕ 3 ( ) = ϕ 3 ([x 1, x 2 ]) = [x 1 + 1, x 2 + 1] Application of worklist algorithm with widening: terminates with expected result for AI 2 ([1, + ]) (on the board) 27 of 27 Static Program Analysis