Exploring Error Detection in Applications: DAIKON and CVR Techniques - Prof. Zbigniew T. K, Assignments of Electrical and Electronics Engineering

A homework assignment for students in ece 542/cs 536 courses, focusing on application-based error detection using daikon and cvr techniques. Students will assess pre-derived assertions, derive new assertions, and evaluate their effectiveness in detecting runtime errors through fault injection. The assignment includes instructions for setting up the environment, conducting experiments, and submitting deliverables.

Typology: Assignments

Pre 2010

Uploaded on 02/24/2010

koofers-user-s0d
koofers-user-s0d 🇺🇸

10 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ECE 542/CS 536 - Homework 4
In this homework, you will explore application-based error detectors. You will
explore two techniques for deriving assertions: (i) DAIKON [1], a dynamic analysis
technique, which derives application invariants based on runtime information; (ii) CVR
[2], a static analysis technique, that extracts the backward slice of a critical variable to
re-compute the variable, thereby detecting errors during runtime. After the assertions
are derived, you will assess their effectiveness in detecting runtime errors using fault
injection.
The homework is divided in two parts:
(I) you will assess a quick sort application with pre-derived assertions and inject
specific faults using GDB to corrupt variables that are checked by the
assertions. This will help you get familiar with fault injection experiments;
(II) you will derive new assertions, using DAIKON and CVR techniques, and
compare both using a fault injector that corrupts an arbitrary data value in
memory. This will help you learn how the assertions are derived and assess their
detection capabilities under random data errors.
Part I
For this part, three versions of a Quick sort application are given. You can
download them from http://courses.ece.uiuc.edu/ece542/hw4/hw-part1.tgz.
Quicksort.c
contains the original application, without any checks.
Quicksort-Daikon.c
has two Daikon invariants embedded in the
Quicksort
function.
Quicksort-Cvr.c
has two checks derived using the CVR technique. The
Quicksort function
contains both checks and also path tracking code.
After understanding the application and the derived checks, you can inject faults
into the protected variables (and their backward slices). Your task is to inject a single
bit-flip fault per run into the protected variables, for both Quicksort-Cvr.c and Quicksort-
Daikon.c. You should have at least 15 runs per program and compare the injection
outcome as it follows:
a) number of injections,
b) number of application crashes (application terminates before reaching a
detector),
c) number of application terminations due to the error being detected,
d) number of fail-silent violations (application completes, but produces incorrect
output),
pf3
pf4

Partial preview of the text

Download Exploring Error Detection in Applications: DAIKON and CVR Techniques - Prof. Zbigniew T. K and more Assignments Electrical and Electronics Engineering in PDF only on Docsity!

ECE 542/CS 536 - Homework 4

In this homework, you will explore application-based error detectors. You will explore two techniques for deriving assertions: (i) DAIKON [1], a dynamic analysis technique, which derives application invariants based on runtime information; (ii) CVR [2], a static analysis technique, that extracts the backward slice of a critical variable to re-compute the variable, thereby detecting errors during runtime. After the assertions are derived, you will assess their effectiveness in detecting runtime errors using fault injection.

The homework is divided in two parts:

(I) you will assess a quick sort application with pre-derived assertions and inject specific faults using GDB to corrupt variables that are checked by the assertions. This will help you get familiar with fault injection experiments;

(II) you will derive new assertions, using DAIKON and CVR techniques, and compare both using a fault injector that corrupts an arbitrary data value in memory. This will help you learn how the assertions are derived and assess their detection capabilities under random data errors.

Part I

For this part, three versions of a Quick sort application are given. You can download them from http://courses.ece.uiuc.edu/ece542/hw4/hw-part1.tgz.

  • Quicksort.c contains the original application, without any checks.
  • Quicksort-Daikon.c has two Daikon invariants embedded in the Quicksort function.
  • Quicksort-Cvr.c has two checks derived using the CVR technique. The Quicksort function contains both checks and also path tracking code.

After understanding the application and the derived checks, you can inject faults into the protected variables (and their backward slices). Your task is to inject a single bit-flip fault per run into the protected variables, for both Quicksort-Cvr.c and Quicksort- Daikon.c. You should have at least 15 runs per program and compare the injection outcome as it follows: a) number of injections, b) number of application crashes (application terminates before reaching a detector), c) number of application terminations due to the error being detected, d) number of fail-silent violations (application completes, but produces incorrect output),

e) number of successful executions of the application (application completes and produces correct output).

You can run this homework in any Unix machine. For fault injection, you can use GDB. If you want to automate the process, you are welcome to use other fault injection techniques. However, you should ensure that you are corrupting the protected variables (and their backward slices) and you are corrupting them by a single bit-flip. Here you can find a minimal set of commands which can be used to set/clear breakpoints, corrupt and inspect values with GDB. You can find more information in the UNIX manpages or a GDB tutorial [3].

Starting GDB gdb executable Setting a breakpoint b source.c: line_number Running the program run arguments Inspecting a variable print variable_name Setting a value print variable_name=NEW_VALUE print variable_name=variable_name+ Continuing the program after a break continue Clearing a breakpoint clear source.c:line_number

Part II

In this part, you will derive the detectors yourself, embed them in the program and evaluate their effectiveness by conducting fault injection tests. You can download the files for this assignment at http://courses.ece.uiuc.edu/ece542/hw4/hw4-part2.tgz For the Daikon version, you are given a Daikon invariant file ( QSinvariants) , which was derived out of 50 runs of the quick sort program. You do not need to run Daikon yourself, but you are welcome to test if you want get a sense of how the tool works. You can download it from http://groups.csail.mit.edu/pag/daikon/. However, you should be aware that it might take many hours to run (each run produces a 500 Mb file). You should choose 2 checks from the invariants derived for the Quicksort function, which can be extracted from the entry or exit point. Certify that your application can run with the check even when you are not injecting faults. For the CVR version, you should derive two checks to protect j and a[j]. You are expected to manually derive their backward slices and add the path tracking code

  1. Each group member must individually contribute to the assignment but is encouraged to work together with other group members on the homework. However, there should be no sharing of code or data among groups.
  2. The experiments do not require any specific machine. However, if needed, you can have access to a Linux machine in CSL 241. If you need access to it and to CSL after-hours, please contact us after class or by email.

References

[1] Michael D. Ernst, Jake Cockrell, William Griswold, David Notkin. Dynamically Discovering Likely Program Invariants to Support Program Evolution. ICSE 1999. 213-

[2] Karthik Pattabiraman, Zbigniew Kalbarczyk, Ravishankar K. Iyer. Automated Derivation of Application-aware Error Detectors using Static Analysis. IOLTS 2007: 211-

[3] Richard Stallman, Roland H. Pesch. Debugging with GDB - The GNU Source-Level Debugger. http://theory.uwinnipeg.ca/gnu/gdb/gdb_toc.html