KLEE error reports

When KLEE detects an error in the program being executed it will generate a test case which exhibits the error, and write some additional information about the error into a file testN.TYPE.err, where N is the test case number, and TYPE identifies the kind of error. Some types of errors KLEE detects include:

• ptr: Stores or loads of invalid memory locations.
• free: Double or invalid free().
• abort: The program called abort().
• assert: An assertion failed.
• div: A division or modulus by zero was detected.
• user: There is a problem with the input (invalid klee intrinsic calls) or the way KLEE is being used.
• exec: There was a problem which prevented KLEE from executing the program; for example an unknown instruction, a call to an invalid function pointer, or inline assembly.
• model: KLEE was unable to keep full precision and is only exploring parts of the program state. For example, symbolic sizes to malloc are not currently supported, in such cases KLEE will concretize the argument.

A way to fix some errors is to use the klee_assume intrinsic function. klee_assume takes a single argument (an unsigned integer) which generally should some kind of conditional expression, and “assumes” that expression to be true on the current path (if that can never happen, i.e. the expression is provably false, KLEE will report an error).

We can use klee_assume to cause KLEE to only explore states where the string is null terminated by writing the driver like this:

    int main() {      // The input regular expression.      char re[SIZE];      // Make the input symbolic.       klee_make_symbolic(re, sizeof re, "re");      klee_assume(re[SIZE - 1] == '\0');      // Try to match against a constant string "hello".      match(re, "hello");      return 0;    }

NOTE: One important caveat when using klee_assume with multiple conditions; remember that boolean conditionals like ‘&&’ and ‘||’ may be compiled into code which branches before computing the result of the expression. In such situations KLEE will branch the process before it reaches the call to klee_assume, which may result in exploring unnecessary additional states. For this reason it is good to use as simple expressions as possible to klee_assume (for example splitting a single call into multiple ones), and to use the ‘&’ and ‘|’ operators instead of the short-circuiting ones.

Reference:
http://klee.github.io/tutorials/testing-regex/