The minimum consistent DFA problem cannot be approximated within any polynomial
Journal of the ACM (JACM)
Precise interprocedural dataflow analysis via graph reachability
POPL '95 Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Yesterday, my program worked. Today, it does not. Why?
ESEC/FSE-7 Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering
A slicing-based approach for locating type errors
ACM Transactions on Software Engineering and Methodology (TOSEM)
The SLAM project: debugging system software via static analysis
POPL '02 Proceedings of the 29th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Verisim: Formal Analysis of Network Simulations
IEEE Transactions on Software Engineering
Simplifying and Isolating Failure-Inducing Input
IEEE Transactions on Software Engineering
Introduction To Automata Theory, Languages, And Computation
Introduction To Automata Theory, Languages, And Computation
Introduction to Algorithms
Isolating cause-effect chains from computer programs
Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering
From symptom to cause: localizing errors in counterexample traces
POPL '03 Proceedings of the 30th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Fate and Free Will in Error Traces
TACAS '02 Proceedings of the 8th International Conference on Tools and Algorithms for the Construction and Analysis of Systems
STOC '04 Proceedings of the thirty-sixth annual ACM symposium on Theory of computing
What went wrong: explaining counterexamples
SPIN'03 Proceedings of the 10th international conference on Model checking software
| Hi-index | 0.00 |
When a system fails to satisfy its specification, the model checker produces an error trace (or counter-example) that demonstrates an undesirable behavior, which is then used in debugging the system. Error explanation is the task of discovering errors in the system or the reasons why the system exhibits the error trace. While there has been considerable recent interest in automating this task and developing tools based on different heuristics, there has been very little effort in characterizing the computational complexity of the problem of error explanation. In this paper, we study the complexity of two popular heuristics used in error explanation. The first approach tries to compute the smallest number of system changes that need to be made in order to ensure that the given counter-example is no longer exhibited, with the intuition being that these changes are the errors that need fixing. The second approach relies on the observation that differences between correct and faulty runs of a system shed considerable light on the sources of errors. In this approach, one tries to compute the correct trace of the system that is closest to the counter-example. We consider three commonly used abstractions to model programs and systems, namely, finite state Mealy machines, extended finite state machines and pushdown automata. We show that the first approach of trying to find the fewest program changes is NP-complete no matter which of the three formal models is used to represent the system. Moreover we show that no polynomial factor approximation algorithm for computing the smallest set of changes is possible, unless P = NP. For the second approach, we present a polynomial time algorithm that finds the closest correct trace, when the program is represented by a Mealy machine or a pushdown automata. When the program is represented by an extended finite state machine, the problem is once again NP-complete, and no polynomial factor approximation algorithm is likely.