Regulatory agencies, such as US FDA, and other third party reviewers of software have the task of comprehending a piece of software in the event of its failure. Program slicing is the preferred technique to analyze software failures. However, program slicing might yield extremely large slices and also demand that an user have intimate knowledge of the software (by specifying a slicing criterion).

In this paper we propose solutions to ameliorate both of these problems. The main hypothesis of the paper is that error reports can be used to generate slicing criteria, thus allowing a third-party reviewer to use slicing without any knowledge of the system being analyzed. The first contribution of the paper is a study of how error reports can be formalized and how execution sequences (called error traces) that satisfy an error report can be identified, which can then be sliced. A primary feature of this work is that incomplete error reports could be dealt with.

The second contribution of the paper is a scheme for using abstract interpretation in the generation of error traces and (potential) slicing criteria from error reports. These "abstract" error traces can be sliced, much like in dynamic/ conditional slicing, with respect to the criteria generated, allowing for inputs to be used to reduce the size of slices. Furthermore, being abstract in nature, they are shorter than exact execution sequences and also allow for easier comprehension. We finally present a case study involving a medical device that illustrates how our approach can aid with program comprehension.