Application of program slicing in algorithmic debugging
Introduction
Since the very first computer program was written, debugging has been an integral part of software development. The cost of debugging is well known. For example, telecommunications industry statistics show that removing programming defects accounts for 40 to 70% of the total expense [9]. Although this estimate also includes preventive efforts, debugging is the second largest expense category after new-feature introduction.
Given the high cost of debugging, it is not surprising that attempts have been made to automate this task 2, 5, 6, 7. The Algorithmic Debugging Technique, introduced by Shapiro [11], was the first attempt to lay a theoretical framework for program debugging and to take this framework as a basis for a partly automatic debugger. In this system the programmer, by answering questions, supplies a partial specification of the program during the bug localization process. However Shapiro's model cannot handle side-effects or loops, and has only been applied to Prolog programs. This restriction prevents the system from being practically useful for programs written in imperative languages.
Furthermore, a major drawback of algorithmic debugging is the great number of user interactions during the debugging process. Thus, an important improvement would be to supply the debugging system with some information which can reduce this number.
Our work on interprocedural dynamic slicing is part of a project on semi-automatic debugging. We have developed a Generalized Algorithmic Debugging Technique/Tool (GADT) 8, 12which is generally applicable to programs written in imperative languages. Our developed slicing technique is used to increase the degree of automation provided by GADT.
In this paper, we present the generalized algorithmic debugging method for imperative languages which allows the constructive use of code with side-effects. We also demonstrate a major improvement in the bug-localization process by combining program slicing with algorithmic debugging.
Section snippets
Functional overview of the debugging system
We divide our algorithmic debugging methodology into three major phases: a transformation phase, a tracing phase and a debugging phase. The last phase consists of three components: algorithmic debugging, test database lookup and dynamic slicing (Fig. 1).
The basic principles of the algorithmic program debugging
Algorithmic program debugging, originally defined by Shapiro [11], is an interactive process where the debugging system acquires knowledge about the intended behavior of the debugged program and uses this knowledge to localize errors. The knowledge is collected by the system through a number of questions to the user.
The algorithmic program debugger can be invoked by the user after noticing an externally visible symptom of a bug. The debugger executes the program and builds a trace execution
Program slicing and algorithmic debugging: a symbiosis
Our goal is to provide a more powerful debugging tool by adding the slicing component in the debugging phase. The debugging system builds an execution tree of all procedure calls in the tracing phase, then algorithmic debugging interacts with the user by asking questions about the intended behavior of the program. The reason for activating the slicing component of the system is that sometimes the algorithmic debugger asks questions about procedures which do not have any relevance to the
A new bug localization algorithm
The incorporation of slicing techniques and application of the test database in GADT demands a slight change in the bug localization algorithm described in Section 3.
The algorithmic debugger interacts with the user through queries about the intended program behavior while traversing the summary graph. During the graph traversal, at each step a query is formulated by this component. Before interacting with the user, the algorithmic debugger checks with two existing sources of information. These
Bug localization levels in GADT
As discussed earlier, debugging is the process of finding the suspect code in the program which caused the error. To start with, the entire program is suspected. The programmer tries to reduce the suspect code to smaller pieces of program code. The process terminates when the suspect code is a single statement of the program. This process is usually performed on two different abstraction levels: the global and the local level.
Global level bug localization refers to the process of examining the
Unlinked reference
••• Ref. [13]appears in the reference list but not in the text. •••
References (13)
- A.V. Aho, R. Sethi, J.D. Ullman, Compilers: Principles, Techniques and Tools, Addison-Wesley, New York,...
- M. Ducassé, A.M. Emde, State of the art in automated program debugging, technical report, European Computer Industry,...
- P. Fritzson, M. Auguston, N. Shahmehri, Using assertions in declarative and operational models for semi-automated...
- P. Fritzson, T. Gyimothy, M. Kamkar, N. Shahmehri, Generalized algorithmic debugging and testing, in: Proceeding of the...
- K.B. Gallagher, Using program slicing in software maintenance, PhD thesis, University of Maryland, College Park, MD,...
- M. Kamkar, P. Krajina, P. Fritzson, Dynamic slicing of parallel message-passing programs, in: Proceedings of the Fourth...
Cited by (14)
Automated debugging based on a constraint model of the program and a test case
2012, Journal of Logic and Algebraic ProgrammingAn efficient interprocedural dynamic slicing method
2006, Journal of Systems and SoftwareComputation of intraprocedural dynamic program slices
2003, Information and Software TechnologyOn the computational complexity of dynamic slicing problems for program schemas
2011, Mathematical Structures in Computer ScienceNRPredictor: an ensemble learning and feature selection based approach for predicting the non-reproducible bugs
2023, International Journal of System Assurance Engineering and ManagementIM<inf>NRFixer</inf>: A hybrid approach to alleviate class-imbalance problem for predicting the fixability of Non-Reproducible bugs
2023, Journal of Software: Evolution and Process