Fault Localization Models in Debugging

Debugging is considered as a rigorous but important feature of software engineering process. Since more than a decade, the software engineering research community is exploring different techniques for removal of faults from programs but it is quite difficult to overcome all the faults of software programs. Thus, it is still remains as a real challenge for software debugging and maintenance community. In this paper, we briefly introduced software anomalies and faults classification and then explained different fault localization models using theory of diagnosis. Furthermore, we compared and contrasted between value based and dependencies based models in accordance with different real misbehaviours and presented some insight information for the debugging process. Moreover, we discussed the results of both models and manifested the shortcomings as well as advantages of these models in terms of debugging and maintenance.Comment: 58-6

Bringing Back-in-Time Debugging Down to the Database

With back-in-time debuggers, developers can explore what happened before observable failures by following infection chains back to their root causes. While there are several such debuggers for object-oriented programming languages, we do not know of any back-in-time capabilities at the database-level. Thus, if failures are caused by SQL scripts or stored procedures, developers have difficulties in understanding their unexpected behavior. In this paper, we present an approach for bringing back-in-time debugging down to the SAP HANA in-memory database. Our TARDISP debugger allows developers to step queries backwards and inspecting the database at previous and arbitrary points in time. With the help of a SQL extension, we can express queries covering a period of execution time within a debugging session and handle large amounts of data with low overhead on performance and memory. The entire approach has been evaluated within a development project at SAP and shows promising results with respect to the gathered developer feedback.Comment: 24th IEEE International Conference on Software Analysis, Evolution, and Reengineerin

Handling pointers and unstructured statements in the forward computed dynamic slice algorithm

Different program slicing methods are used for debugging, testing, reverse engineering and maintenance. Slicing algorithms can be classified as a static slicing or dynamic slicing type. In applications such as debugging the computation of dynamic slices is more preferable since it can produce more precise results. In a recent paper [5] a new so-called "forward computed dynamic slice" algorithm was introduced. It has the great advantage compared to other dynamic slice algorithms that the memory requirements of this algorithm are proportional to the number of different memory locations used by the program, which in most cases is much smaller than the size of the execution history. The execution time of the algorithm is linear in the size of the execution history. In this paper we introduce the handling of pointers and the jump statements (goto, break, continue) in the C language

On the computational complexity of dynamic slicing problems for program schemas

This is the preprint version of the Article - Copyright @ 2011 Cambridge University PressGiven a program, a quotient can be obtained from it by deleting zero or more statements. The field of program slicing is concerned with computing a quotient of a program that preserves part of the behaviour of the original program. All program slicing algorithms take account of the structural properties of a program, such as control dependence and data dependence, rather than the semantics of its functions and predicates, and thus work, in effect, with program schemas. The dynamic slicing criterion of Korel and Laski requires only that program behaviour is preserved in cases where the original program follows a particular path, and that the slice/quotient follows this path. In this paper we formalise Korel and Laski's definition of a dynamic slice as applied to linear schemas, and also formulate a less restrictive definition in which the path through the original program need not be preserved by the slice. The less restrictive definition has the benefit of leading to smaller slices. For both definitions, we compute complexity bounds for the problems of establishing whether a given slice of a linear schema is a dynamic slice and whether a linear schema has a non-trivial dynamic slice, and prove that the latter problem is NP-hard in both cases. We also give an example to prove that minimal dynamic slices (whether or not they preserve the original path) need not be unique.This work was partly supported by the Engineering and Physical Sciences Research Council, UK, under grant EP/E002919/1

Graph Mining for Software Fault Localization: An Edge Ranking based Approach

Fault localization is considered one of the most challenging activities in the software debugging process. It is vital to guarantee software reliability. Hence, there has been a great demand for automated methods that can pinpoint faults for software developers. Various fault localization techniques that are based on graph mining have been proposed in the literature. These techniques rely on detecting discriminative sub-graphs between failing and passing traces. However, these approaches may not be applicable when the fault does not appear in a discriminative pattern. On the other hand, many approaches focus on selecting potentially faulty program components (statements or predicates) and then ranking these components according to their degree of suspiciousness. One of the difficulties encountered by such approaches is to understand the context of fault occurrence. To address these issues, this paper introduces an approach that helps in analyzing the context of execution traces based on control flow graphs. The proposed approach uses the edge-ranking of basic blocks in software programs using Dstar that proved to be more effective than many fault localization techniques. The proposed method helps in detecting some types of faults that could not be previously detected by many other approaches. Using Siemens benchmark, experiments show the effectiveness of the proposed technique compared to some well-known approaches such as Dstar, Tarantula, SOBER, Cause Transition and Liblit05. The percentage of localized faulty versions versus the percentage of code examined is taken as a measure. For instance, when the percentage of examined code is 30%, the proposed technique can localize nearly 81% of the faulty versions, which outperforms the other four techniques