Efficient debugging with slicing and backtracking (original) (raw)

Debugging with Dynamic Slicing and Backtracking

Software - Practice and Experience, 1993

Programmers spend considerable time debugging code. Symbolic debuggers provide some help but the task remains complex and difficult. Other than breakpoints and tracing, these tools provide little high-level help. Programmers must perform many tasks manually that the tools could perform automatically, such as finding which statements in the program affect the value of an output variable for a given test case, and what was the value of a given variable when the control last reached a given program location. If debugging tools provided explicit support for these tasks, the debugging process could be automated to a significant extent.In this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research.

An Execution Backtracking Approach to Program Debugging

An execution backtracking facility in interactive source debuggers allows users to mirror their thought processes while debugging-working backwards from the location where an error is manifested and determining the conditions under which the error occurred. Such a facility also allows a user to change program characteristics and reexecute from arbitrary points within the program under examination-a "what-if" capability. This paper describes an experimental debugger that provides such a backtracking function. We describe why the facility is useful, and why other current techniques are inadequate. We show how execution backtracking can be efficiently implemented by saving only the latest values of variables modified by a statement, and allowing backtracking only over complete program statements. We also describe how this approach relates to our work on dynamic program slicing.

Combining algorithmic debugging and program slicing

Proceedings of the 8th ACM SIGPLAN symposium on Principles and practice of declarative programming - PPDP '06, 2006

Currently, program slicing and algorithmic debugging are two of the most relevant debugging techniques for declarative languages. They help programmers to find bugs in a semiautomatic manner. On the one hand, program slicing is a technique to extract those program fragments that (potentially) affect the values computed at some point of interest. On the other hand, algorithmic debugging is able to locate a bug by automatically generating a series of questions and processing the programmer's answers. In this work, we show for functional languages how the combination of both techniques produces a more powerful debugging schema that reduces the number of questions that programmers must answer to locate a bug.

Dynamic slicing object-oriented programs for debugging

Proceedings. Second IEEE International Workshop on Source Code Analysis and Manipulation

Dynamic program slicing is an effective technique for narrowing the errors to the relevant parts of a program when debugging. Given a slicing criterion, the dynamic slice contains only those statements that actually affect the variables in the slicing criterion. This paper proposes a method to dynamically slice object-oriented (OO) programs based on dependence analysis. It uses the object program dependence graph and other static information to reduce the information to be traced during program execution. It deals with OO features such as inheritance, polymorphism and dynamic bindings. Based on this model, we present methods to slice methods, objects and classes. We also modify the slicing criterion to fit for debugging.

The value of slicing while debugging

Science of Computer Programming, 2001

The paper describes a study that explored the relationship of program slicing to (1) code understanding gained while debugging, and to (2) a debugger's ability to localize the program fault area. The study included two experiments. The ÿrst experiment compared the program understanding abilities of two classes of debuggers: those who slice while debugging and those who do not. For debugging purposes, a slice can be thought of as a minimal subprogram of the original code that contains the program faults. Those who only examine statements within a slice for correctness are considered slicers; all others are considered non-slicers. Using accuracy of subprogram construction as a measure of understanding, it was determined that slicers have a better understanding of the code after debugging. The second experiment compared debugger fault localization abilities before and after a training session on how to use slicing in debugging. Using time as a measure of ability, it was shown that slicing while debugging improves a debugger's ability to localize the program fault area.

An execution-backtracking approach to debugging

1991

Abstract Spyder, a system for selective checkpointing of computational sequences, is presented. It lets users backtrack from checkpoints without the need to reexecute the program to reach recent prior states. In contrast to more comprehensive (and storage-intensive) checkpointing schemes, backtracking in this approach is constrained to limit storage requirements. The resulting debugger offers a structured view of dynamic events, similar to lexical scope rules' effect on static visibility.

Enhancing Trace Debugging with Algorithmic and Omniscient Debugging

2013

During many years, Print Debugging has been the most used method for debugging. Nowadays, however, industrial languages come with a trace debugger that allows programmers to trace computations step by step. Almost all modern programming environments include debugging utilities that allows us to place breakpoints and to inspect the state of a computation in any given point. Nevertheless, this debugging method has been criticized for being completely manual and time-consuming. Other debugging techniques have appeared to solve some of the problems of Trace Debugging, but they suffer from other problems such as scalability. In this work we present a new hybrid debugging technique. It is based on a combination of Trace Debugging, Algorithmic Debugging and Omniscient Debugging to produce a synergy that exploits the best properties and strong points of each technique. We describe the architecture of our hybrid debugger and our implementation that has been integrated into Eclipse as a plugin.

Programmers Should Still Use Slices When Debugging

2016

What is the best technique for fault localization? In a study of 37 real bugs (and 37 injected faults) in more than a dozen open source C programs, we compare the effectiveness of statistical debugging against dynamic slicing—the first study ever to compare the techniques. On average, dynamic slicing is more effective than statistical debugging, requiring programmers to examine only 14% (42 lines) of the code before finding the defect, less than half the effort required by statistical debugging (30% or 157 lines). Best results are obtained by a hybrid approach: If programmers first examine the top five most suspicious locations from statistical debugging, and then switch to dynamic slices, they will need to examine only 11% (35 lines) of the code.

A Revitalizing Dynamic Slicing Method for Program Testing and Debugging

We have presented here our extended discussion for handling user-defined and derived data types by interprocedural dynamic slicing techniques as well as slicing applications for testing and debugging of programs. At first an extended interprocedural dynamic slicing algorithm has been proposed for obtaining dynamic slices for different derived and user defined data types. Secondly their implementations are shown on different programs where slices are being obtained. The program is tested and then debugged by slicing techniques. At first we seed some errors in the program and then the behaviour of the program is checked against the correct program, where the program gets tested and their slices are maintained. Then the program gets debugged. Those slices are stored in a linear data structure which can be referred further to know where an error has been occurred from the behaviour the program. The proposed extended algorithm is more efficient then the existing algorithm as it gives a d...

An Analysis of the Current Program Slicing and Algorithmic Debugging Based Techniques

2008

slice provides additional information: it says for each statement in the slice if the condition c =‘\n’ will be satisfied or not. (1) read(text); [false] (2) read(n); [false] (3) lines = 1; [c!=‘\n’] (4) chars = 1; [false] (5) subtext = ""; [false] (6) c = getChar(text); [false] (7) while (c != ‘\eof’) [false] (8) if (c == ‘\n’) [false] (9) then lines = lines + 1; [false] (10) chars = chars + 1; [false] (11) else chars = chars + 1; [false] (12) if (n != 0) [false] (13) then subtext = subtext ++ c; [false] (14) n = n 1; [false] (15) c = getChar(text); [false] (16) write(lines); [c!=‘\n’] (17) write(chars); [false] (18) write(subtext); [false] Fig. 23. Abstract slice of Figure 1 (a) with respect to 〈16, c =‘\n’, [(1), text = “hello world!\eof”]〉 Question answered: Under which variable values do the program’s statements affect or are affected by the slicing criterion? Main applications: Program comprehension. 2.24 Amorphous Slicing (Harman and Danicic, 1997) All approaches to...