Bandera: Extracting Finitestate Models from Java Source Code

1
Bandera Extracting Finite-state Models from Java
Source Code
Students and Post-doc
Faculty
U. Hawaii Kansas State Kansas State
Kansas State Kansas State Kansas
State Kansas State Kansas State

• James Corbett
• Matthew Dwyer
• John Hatcliff

Shawn Laubach Corina Pasareanu Robby Hongjun
Zheng Oksana Tkachuk
2
Goal Increase Software Reliability
Trends
Size, complexity, concurrency, distributed
Cost of software engineer.
Cost of CPU cycle..
Future Automated Fault Detection
3
The Dream
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
OK
Program
or
Error trace
Checker
Property 1 Property 2
Requirement
4
Model Checking
OK
Finite-state model
or
Error trace
Model Checker
(F W)
Line 5 Line 12 Line 15 Line 21 Line
25 Line 27 Line 41 Line 47
Temporal logic formula
5
Why use Model Checking?

• Automatically check, e.g.,
• invariants, simple safety liveness properties
• absence of dead-lock and live-lock,
• complex event sequencing properties,

Between the window open and the window close,
button X can be pushed at most twice.

• In contrast to testing, gives complete coverage
  by exhaustively exploring all paths in system,
• Its been used for years with good success in
  hardware and protocol design

This suggests that model-checking can complement
existing software quality assurance techniques.
6
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

7
Model Construction Problem
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
Model Checker
Program
Model Description

• Semantic gap

Programming Languages
methods, inheritance, dynamic creation,
exceptions, etc.
Model Description Languages
automata
8
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

9
Property Specification Problem

• Difficult to formalize a requirement in temporal
  logic

Between the window open and the window close,
button X can be pushed at most twice.
is rendered in LTL as...
((open /\ ltgtclose) -gt ((!pushX /\ !close) U
(close \/ ((pushX /\ !close) U (close \/
((!pushX /\ !close) U (close \/ ((pushX
/\ !close) U (close \/ (!pushX U
close))))))))))
10
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

11
State Explosion Problem

• Cost is exponential in the number of state
  variables

• Moores law and algorithm advances can help
• Holzmann 7 days (1980) ... 7 seconds (2000)
• Need to apply aggressive abstractions
• Holzmann, Stevens, Brinksma,

12
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

13
Output Interpretation Problem
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
Model Description
Program

• Raw error trace may be 1000s of steps long

• Must map line listing onto model description

• Mapping to source is made difficult by

• Semantic gap clever encodings of complex
  features
• multiple optimizations and transformations

14
BanderaAn open tool set for model-checking Java
source code
15
Addressing the Model Construction Problem

• Numerous analyses, optimizations,two
  intermediate languages, multiple back-ends
• Slicing, abstract interpretation, specialization
• Variety of usage modes simple...highly tuned

16
Addressing the Property Specification Problem
An extensible language based on field-tested
temporal property specification patterns
ICSE99
((open /\ ltgtclose) -gt ((!pushX /\ !close) U
(close \/ ((pushX /\ !close) U (close \/
((!pushX /\ !close) U (close \/ ((pushX
/\ !close) U (close \/ (!pushX U
close))))))))))
17
(No Transcript)
18
Addressing the Output Interpretation Problem
Model Description
Intermediate Representations
Model Checker
Model Compiler
Error trace

• Run error traces forwards and backwards
• Program state queried
• Heap structures navigated
• Locks, wait sets, blocked sets displayed

19
Bandera Architecture
20
Front End

• Translates Java source to Jimple IR
• Supports specification of property
• Supports debugger-like facilities for error
  traces

Label1 if (x lt 0) goto Label2
t0 y 2 x t0 Label2
if (x gt 0) x y 2
Java
Jimple
21
Property Specification
/ _at_observable EXP Full (head
tail) / class BoundedBuffer Object
buffer int head, tail, bound public
synchronized void add(Object o)
public synchronized Object take ()
22
Property Specification
23
Property Specification
24
Property Specification
25
Property Specification
forallbBoundedBuffer. Full(b) leads to
!Full(b) globally

• Universal Quantification
• defined over all allocated class instances

• by adding a state variable (for b) that is bound
  to all allocated instances
• by enabling checking of the formula only when
  variable is bound to an instance

26
Property Specification
class Quantified static BoundedBuffer
b class BoundedBuffer Object buffer
int head, tail, bound public BoundedBuffer()
... if (Quantified.b null
Bandera.choose()) Quantified.b this

class BoundedBuffer Object buffer int
head, tail, bound public BoundedBuffer()
...
27
Property-directed Slicing
Source program

• slicing criterion generated automatically from
  observables mentioned in the property

• backwards slicing automatically finds all
  components that might influence the observables.

28
Property-directed Slicing
Program Dependence-based Slicing
SAS99
Thread 1
Thread 2
29
Property-directed Slicing

• Alias analysis
• currently use a form of RTA
• integrating a flexible (flow and
  context-sensitive) alias analysis framework
• Supplementary analyses
• safe-lock analysis SAS99

30
Property-directed Slicing
31
AbstractionSpecializer
Collapses data domains via abstract
interpretation
Data domains
Code
int x 0 if (x 0) x x 1
32
Abstraction Component Functionality
x
int
Signs
y
int
Signs
Signs
done
bool
Bool
Abstraction Library
count
int
intAbs
.
.
o
Object
Point
b
Buffer
Buffer
33
Library of Abstractions
Current Library Contains

• Range(i,j) i..j modeled precisely, e.g.,
• Range(0,0) is the signs abstraction
• Range(2,4) has tokens lt2,2,3,4,gt4
• Modulo(k), e.g.,
• Modulo(2) is the even-odd abstraction
• Specific(v,) identifies values of interest,
  e.g.,
• Specific(10) has tokens eq10,not10
• User extendable for base type predicates

34
Property Preservation

• Slices preserve true and false results
• proof of CTL preservation
• Abstractions preserve true results
• reason about soundness offline
• Restrictions preserve neither
• e.g., limit the number of instances of a class
• used as a last resort to compress model
• still very useful for finding bugs

35
Back End

• Bandera Intermediate Representation (BIR)
• guarded command language
• includes locks, threads, references, heap
• info to help translators (live vars, invisible)

loc s5 live r0, r1 when lockAvail(r0.lock)
do lock(r0.lock) goto s6 loc s6 live
r1 when true do invisible r1.count
0 goto s7
entermonitor r0 r1.count 0
Jimple
BIR
36
Translators

• Plug-in component that interfaces to specific
  model checker
• Translates BIR to checker input language
• Parses output of checker for error trace
• Currently
• SPIN, dSPIN, SMV translators complete
• JPF (from NASA Ames) integrated

37
Output Display

• Counter-examples can be very long and can span
  multiple threads
• Debugger-like features
• forward, backward stepping
• source locations (thread, method, stmt)
• watch variables (local,static,instance)
• searching (source, variable)
• heap display (textual, graphical)

38
Output Display
39
Summary

• Bandera provides an open platform for
  experimentation
• We hope this will contribute to the definition of
  an API for software model-checkers
• Upcoming case studies
• Space/time data for small examples ICSE00
• Bandera specification language SPIN00

40
Related Work

• Lots of abstraction and slicing work
• Back-ends
• Spin, NuSMV
• dSpin, JPF
• SAL (in progress)
• Other source code model-checking
• Java JPF, JCAT, Java/SAL
• C SLAM, Feaver

41
Ongoing Work

• Property specification
• state-dependent quantification
• e.g., quantify over array elements
• More sophisticated abstractions
• whole object abstractions (with identity)
• e.g., exploit escape analyses to identify
  stackable objects
• array abstractions induced by index and element
  abstractions

42
Ongoing Work

• Abstraction selection
• guided by program dependence info
• Translators
• performance tuning
• more targets (XMC, Bebop, UCSB)
• Case studies
• CAN applications
• ...

43
Current Status

• A reasonable subset of concurrent Java
• not handled recursive methods(), exceptions(),
  inner classes, native methods, libraries()
• Public release end of summer 2000

http//www.cis.ksu.edu/santos/bandera
44
Design Goals

• Separate model checking from extraction
• Use existing model checkers
• Support multiple model checkers
• Provide automated support for abstraction
• Slicing
• Abstract interpretation
• Specialization
• Specialize models for specific properties
• Design for extensibility
• Well-defined internal representations and
  interfaces

45
Lack of Integration Problem
Existing Quality Assurance techniques and tools
Debugging
Testing
Simulation
Visualization
Run-time monitoring
Static Analysis

• Monitoring drives checker path selection

• Error traces drive test case generation

• Debugging/Visualization of error traces

46
Bandera Toolset
Property
Model Checkers
Source code
Bandera
47
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State Explosion

• Property specification

• Output Interpretation

48
Goal Increase Software Reliability
Trends
Software Size
Concurrency
Complexity
Cost of Engineer
Cost of CPU cycle
Future Automated Fault Detection
49
Model Checking
OK
Finite-state model
or
Error trace
Model Checker
(F W)
Temporal logic formula