A Specification Logic for Exceptions and Beyond

Cristina DavidCristian Gherghina

National University of Singapore

2

Context(Roy Maxion et al. “Improving software robustness with dependability cases”)

Exception failures◦ Up to 2/3 of system crashes ◦ 50% of system security vulnerabilities

Need for ◦ Specifying behavior even in the presence of

exceptions◦ Precisely defined yet flexible exception safety

guarantees◦ Tools to enforce such specifications

3

ContributionsA specification logic for all control

flow types

An improvement of the classical exception safety guarantees

A verification system for a Java-like language

4

Specification LogicCurrent specification logics fail to

track control flow types

We propose Explicit tracking of control flow

information in the specification logic An unified view of all control flow types

Specification Logic An unified view of the control flow:

Unify both normal and abnormal control flows

Unify both static and dynamic control flows• static flow: break, continue, return• dynamic flow: try-catch, raise

5

Unified control flow hierarchy

staticdynamic

6

dynamic control flows due to exceptions

dynamic control flows due to exceptions static control flows

static control flows

normal execution

normal execution

can be caught

can be caught

cannot be caught

cannot be caught

Specification LogicThe specification formulae are

enriched separation logic formulae

They allow for capturing the states for both normal and exceptional executions

7

Specification Formulae

◦ ¯ captures constraints on flow variables◦ ¿ captures the current flow◦ Current flow values can be:

Exact flow types Subtypes and type differences

8

9

Exception Safety Guarantees

(Stroustrup: Exception Safety: Concepts and Techniques)◦ No-leak guarantee

Exceptions leave the operands in well-defined states Every acquired resources is released

◦ Basic guarantee The class invariants are always maintained Very forgiving with the programmer

◦ Relaxed strong guarantee Precise explicit effect Currently, difficult to specify

◦ Strong guarantee◦ The operation either succeeds or has no effect if an exception is

raised◦ More difficult to implement

◦ No throw guarantee◦ Never throw an exception

No Throw GuaranteeE.g. a swap function

The postcondition specifies that no exceptional flow can escape the swap method

10

Strong GuaranteeAn operation

leaves its operands in well-defined states ensures that every acquired resource is released class invariants are maintained succeeds, or has no effects when an exception occurs

11

Relaxed Strong Guarantee An operation

leaves its operands in well-defined states ensures that every acquired resource is released

eventually class invariants are maintained succeeds, or has a precisely known effect when

an exception occurs

12

Verification SystemTranslates Source Language programs

into Core Language programs◦ (C. David et al.  ”Translation and optimization for

a core calculus with exceptions” PEPM09)

Performs forward verification by computing the strongest post condition

Proven to be sound

13

Source Language SrcLang• Supports constructs challenging from

the point of how control flow is transferred

• finally construct

• multi-return function call

• try catch with multiple handlers

• break and continue statements

14

Core Language• As small as a corresponding one

without exceptions

• Supports the translation of challenging constructs from the source language

• Easier to analyze than the source language

15

16

Source Lang Core Lang

…

Important constructs of the Core Lang

• Flow and value: ft#v • normal flow: norm#v• exceptional flow: ty(v)#v

• Try-catch construct: try e1 catch((c@fv)#v) e2

• captures both exceptional and normal control flow

17

control flow

variable capturing the control flow type (fv<:c)

the thrown value

18

Verification Exampletry {

if (x>0)

compute(x,p)

else

ret#p

}catch(over_exc@fv#v)

brk_l#()

19

Verification Example

if (x>0)

compute(x,p);

else

ret#p

{true & flow=norm}

{x>0 & flow=norm}

{x≤0 & flow = norm}

{(x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)}

{x≤0 & res=p & flow = ret}

{ (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)}

20

Verification Example

try{

…

}catch(over_exc@fv#v)

brk_l#()

{true & flow=norm}

{true & flow=norm}

{v::over_exc() & x>0 & p=0 & flow=norm & fv=over_exc}

{v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc}{(x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x &

flow=norm) 9 v,fv ¢ (x>0 & res=3 & v=x& flow=exception & fv=exception)}

{ (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)}

over_exc <: num_exc

21

Verification Exampletry{…

}catch(over_exc@fv#v) …

{v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc}

{(x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç 9 v,fv ¢ (v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc – over_exc)}

{ (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)}

over_exc <: num_exc

Try-catch and “#” Verification Rules

22

the “caught” states the “uncaught” states

Experimental ResultsSuccessfully verified test

examples from:◦KeY project, exercising specific

features◦SPEC benchmarks, broad range

exception handling

23

24

Related WorkSPEC#

◦ K. Rustan et al. “Exception safety for C#”

KEY project◦ B. Beckert et al. “Verification of

Object-Oriented Software: The KeY Approach”

Type systems◦M. Blume et al. “Exception handlers

as extensible cases”CSP

25

Thank you!

Multi-return function call

26

• Explicitly captures the choice of the return point, based on the control flow caught after the evaluation