ACM Home Page
Please provide us with feedback. Feedback
Explaining abstract counterexamples
Full text PdfPdf (212 KB)
Source Foundations of Software Engineering archive
Proceedings of the 12th ACM SIGSOFT twelfth international symposium on Foundations of software engineering table of contents
Newport Beach, CA, USA
SESSION: Error explanation table of contents
Pages: 73 - 82  
Year of Publication: 2004
ISBN:1-58113-855-5
Also published in ...
Authors
Sagar Chaki  Carnegie Mellon University, Pittsburgh, PA
Alex Groce  Carnegie Mellon University, Pittsburgh, PA
Ofer Strichman  Technion, Haifa, Israel
Sponsors
ACM: Association for Computing Machinery
SIGSOFT: ACM Special Interest Group on Software Engineering
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 5,   Downloads (12 Months): 54,   Citation Count: 3
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1029894.1029908
What is a DOI?

ABSTRACT

When a program violates its specification a model checker produces a counterexample that shows an example of undesirable behavior. It is up to the user to understand the error, locate it, and fix the problem. Previous work introduced a technique for explaining and localizing errors based on finding the closest execution to a counterexample, with respect to a distance metric. That approach was applied only to concrete executions of programs. This paper extends and generalizes the approach by combining it with predicate abstraction. Using an abstract state-space increases scalability and makes explanations more informative. Differences between executions are presented in terms of predicates derived from the specification and program, rather than specific changes to variable values. Reasoning to the cause of an error from the factthat in the failing run x < y, but in the successful execution x = y is easier than reasoning from the information that in the failing run y = 239, but in the successful execution y = 232. An abstract explanation is <i>automatically generalized</i>

Predicate abstraction has previously been used in model checking purely as a state-space reduction technique. However, an abstraction good enough to enable a model checking tool to find an error is also likely to be useful as an <i>automatically generated high-level description of a state space</i> --- suitable for use by programmers. Results demonstrating the effectiveness of abstract explanations support this claim.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
F. Aloul, A. Ramani, I. Markov, and K. Sakallah. PBS: A backtrack search pseudo Boolean solver. In Symposium on the theory and applications of satisfiability testing (SAT), pages 346--353, 2002.
2
 
3
P. Anderson and T. Teitelbaum. Software inspection using CodeSurfer. In Workshop on Inspection in Software Engineering, 2001.
4
 
5
 
6
 
7
 
8
S. Chaki, E. Clarke, A. Groce, and O. Strichman. Predicate abstraction with minimum predicates. In Advanced Research Working Conference on Correct Hardware Design and Verification Methods (CHARME), pages 19--34, 2003.
 
9
 
10
E. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 2000.
 
11
 
12
 
13
A. Groce. Error explanation with distance metrics. In Tools and Algorithms for the Construction and Analysis of Systems, pages 108--122, 2004.
 
14
A. Groce, D. Kroening, and F. Lerda. Understanding counterexamples with explain. In Computer-Aided Verification, 2004. To appear.
 
15
A. Groce and W. Visser. What went wrong: Explaining counterexamples. In SPIN Workshop on Model Checking of Software, pages 121--135, 2003.
16
17
 
18
 
19
D. Kroening, E. Clarke, and F. Lerda. A tool for checking ANSI-C programs. In Tools and Algorithms for the Construction and Analysis of Systems, pages 168--176, 2004.
 
20
D. Lewis. Causation. Journal of Philosophy, 70:556--567, 1973.
 
21
M. Renieris and S. Reiss. Fault localization with nearest neighbor queries. In Automated Software Engineering, pages 30--39, 2003.
 
22
 
23
D. Sankoff and J. Kruskal, editors. Time Warps, String Edits, and Macromolecules: the Theory and Practice of Sequence Comparison. Addison Wesley, 1983.
24
 
25


Collaborative Colleagues:
Sagar Chaki: colleagues
Alex Groce: colleagues
Ofer Strichman: colleagues