adraghici / srtool Goto Github PK

To score a very high mark for Part 2 of the coursework you will need to implement some innovative features to make your tool perform especially well. You can be creative in this, but here are some ideas (in no particular order).
• To find bugs more effectively you could try implementing a simple dynamic symbolic execution algo- rithm to explore individual program paths individually.
• To find bugs you could also try compiling a Simple C program into a C program, and running the C program with random inputs in an attempt to trigger assertion failures. You would have to find a suitable way to represent non-C language features.
• To boost verification, you could implement some strategies for guessing candidate loop invariants to be used as input to Houdini, because the input program might not contain sufficient loop invariants and candidate loop invariants to enable verification.
• For verification, you could implement sound bounded model checking (with unwinding assertions).
• You could experiment with running a variety of analyses in parallel, returning the first useful result that
is returned by an analysis.

Implement loop summarisation, so that your tool can successfully verify single-procedure programs for which sufficient non-candidate loop invariants are provided.

This is similar to the implementation of assume statements.

Failing Tests (39):
SRT :: tests/official/part2/correct/part2_correct_11.c
SRT :: tests/official/part2/correct/part2_correct_13.c
SRT :: tests/official/part2/correct/part2_correct_143.c
SRT :: tests/official/part2/correct/part2_correct_17.c
SRT :: tests/official/part2/correct/part2_correct_23.c
SRT :: tests/official/part2/correct/part2_correct_29.c
SRT :: tests/official/part2/correct/part2_correct_35.c
SRT :: tests/official/part2/correct/part2_correct_39.c
SRT :: tests/official/part2/correct/part2_correct_41.c
SRT :: tests/official/part2/correct/part2_correct_55.c
SRT :: tests/official/part2/correct/part2_correct_59.c
SRT :: tests/official/part2/correct/part2_correct_63.c
SRT :: tests/official/part2/correct/part2_correct_79.c
SRT :: tests/official/part2/correct/part2_correct_85.c
SRT :: tests/official/part2/correct/part2_correct_89.c
SRT :: tests/official/part2/correct/part2_correct_9.c
SRT :: tests/official/part2/incorrect/part2_incorrect_107.c
SRT :: tests/official/part2/incorrect/part2_incorrect_11.c
SRT :: tests/official/part2/incorrect/part2_incorrect_119.c
SRT :: tests/official/part2/incorrect/part2_incorrect_13.c
SRT :: tests/official/part2/incorrect/part2_incorrect_15.c
SRT :: tests/official/part2/incorrect/part2_incorrect_17.c
SRT :: tests/official/part2/incorrect/part2_incorrect_21.c
SRT :: tests/official/part2/incorrect/part2_incorrect_23.c
SRT :: tests/official/part2/incorrect/part2_incorrect_25.c
SRT :: tests/official/part2/incorrect/part2_incorrect_31.c
SRT :: tests/official/part2/incorrect/part2_incorrect_33.c
SRT :: tests/official/part2/incorrect/part2_incorrect_35.c
SRT :: tests/official/part2/incorrect/part2_incorrect_37.c
SRT :: tests/official/part2/incorrect/part2_incorrect_43.c
SRT :: tests/official/part2/incorrect/part2_incorrect_45.c
SRT :: tests/official/part2/incorrect/part2_incorrect_49.c
SRT :: tests/official/part2/incorrect/part2_incorrect_61.c
SRT :: tests/official/part2/incorrect/part2_incorrect_63.c
SRT :: tests/official/part2/incorrect/part2_incorrect_65.c
SRT :: tests/official/part2/incorrect/part2_incorrect_69.c
SRT :: tests/official/part2/incorrect/part2_incorrect_81.c
SRT :: tests/official/part2/incorrect/part2_incorrect_9.c
SRT :: tests/official/part2/incorrect/part2_incorrect_91.c

Implement the Houdini algorithm for procedures with loops, initially assuming that candidate pre/post- conditions are not provided (so that the only candidates in a program are candidate loop invariants). Your tool should then be capable of proving correctness of loops for which the given Houdini candidates provide at least the invariants needed for verification.

Implement procedure summarisation, so that your tool can successfully verify multi-procedure programs for which sufficient non-candidate loop invariants, preconditions and postconditions are provided.

Implement an incremental approach to bounded model checking, so that successively larger loop un- winding depths are considered until a bug is found.

Have your srtool script run two analyses in parallel: one that looks for bugs, using unsound BMC, another that attempts verification, using loop- and procedure-summarisation.

Implement the Houdini algorithm for programs where procedures have candidate pre/postconditions as well as candidate loop invariants. Ensure that your tool can prove correctness of programs for which sufficient candidates are provided.

Implement unsound bounded model checking, giving your tool an option for controlling the loop un- winding depth, so that your tool can find bugs in incorrect programs with loops.

This is similar to assertion checking.

• disable debug 'states' to reduce memory footprint