Dynamically Discovering Likely Program Invariants All material in this presentation is derived from documentation online at the Daikon website, and from publications by Michael D. Ernst, Jake Cockrell, William G. Griswold, and David Notkin. Presented by Neeraj Khanolkar

Daikon Means.. A daikon is a type of Asian radish. Daikon is pronounced like the two English words die-con. The name can be thought of as standing for "dynamic conjectures".

Current Release of Daikon Is completely written in Java. (Needs JVM 1.5 to run) Is quite easy to install and use for inference on Java programs. (Simply put daikon.jar in your classpath) Has a rich suite of tools operating on invariants. (Daikon tools can be used to print the inferred invariants in JML format, and to automatically annotate source files with the JML specs)

Original Program Instrumented Program Instrumentation Data trace database Execution with test suite Invariants Detection of Invariants Architecture of the Daikon tool

A Simple Example public class ArraySum{ private void dummy(int sum, int[] theArray){ }... public int getSum(int[] b){ int i = 0; int s = 0; int n = b.length; while(i != n){ s = s + b[i]; i = i + 1; } this.dummy(s,b); return s; } The call to dummy(s,b) is a hack to record the local variable s. Daikon's current front ends do not produce output for local variables, only for variables visible from outside a procedure.

Daikon Output In JML Format ArraySum.getSum(int[]):::ENTER Variables: … b != null (daikon.Quant.size(b) >> daikon.Quant.size(b)-1 == 0) =================================================== ArraySum.getSum(int[]):::EXIT Variables: … assignable b, b[*] daikon.Quant.pairwiseEqual(b, \old(b)) \result != daikon.Quant.size(b)-1 (\old(daikon.Quant.size(b)) >> daikon.Quant.size(b)-1 == 0)

Simple Example II public class ArraySum{... public int[] getReverse(int[] b){ int[] reverse = new int[b.length]; for(int i = 0; i < reverse.length; i++){ reverse[i] = b[reverse.length - i - 1]; } return reverse; }... }

Daikon Output In JML Format ArraySum.getReverse(int[]):::ENTER Variables: …. b != null (daikon.Quant.size(b) >> daikon.Quant.size(b)-1 == 0) =================================================== ArraySum.getReverse(int[]):::EXIT Variables: … assignable b, b[*] daikon.Quant.pairwiseEqual(b, \old(b)) daikon.Quant.size(\result) == \old(daikon.Quant.size(b)) \result != null daikon.Quant.isReverse(b, \result) daikon.Quant.size(\result) >> daikon.Quant.size(b)-1 == 0)

What Invariants Are Inferred? Invariants over any variable –Constant Value –Uninitialized Invariants over a single numeric variable –Range limits –Non-zero Invariants over two numeric variables –Linear relationship y = ax + b –Ordering comparison

What Invariants Are Inferred? Invariants over three numeric variables Invariants over a single sequence variable –Range: Minimum and maximum sequence values –Element ordering Invariants over two sequence variables –Subsequence relationship –Reversal Invariants over a sequence and a numeric variable

How Are Invariants Inferred? For each variable or tuple of variables, each potential invariant is tested. For instance, given 3 variables x, y and z –Each potential binary invariant is checked for, for and for. –Each potential unary invariant is checked for x, for y and for z. –Each potential ternary invariant is checked for.

How Are Invariants Inferred? A sample is a tuple of values for the instrumented variables at a program point, stemming from one execution of that program point. An invariant is checked by testing each sample in turn. As soon as a sample not satisfying the invariant is encountered, the invariant is known not to hold and is not checked for any subsequent samples.

Additional Derived Variables From sequence s –Length i.e. size(s) –Extremal elements: s[0], s[size(s) – 1] From any numeric sequence s –Minimum and maximum: min(s) and max(s) From any sequence s and any numeric variable i –Element at index s[i] –Subsequence s[0..i] From function invocations –Number of calls

Inferred Invariants Useful In Modifying Programs. (Case Study Experience) Explicated data structures. Confirmed and contradicted expectations. Revealed a bug. Demonstrated test suite inadequacy. Validated program changes.