Abstract Interpretation of Programs for Model-Based Debugging
Total Page：16
File Type：pdf, Size：1020Kb
Abstract Interpretation of Programs for Model-Based Debugging Wolfgang Mayer Markus Stumptner Advanced Computing Research Centre University of South Australia [mayer,mst]@cs.unisa.edu.au Language Abstract Semantics Test-Cases Developing model-based automatic debugging strategies has been an active research area for sev- Program eral years. We present a model-based debug- Conformance Test Components ging approach that is based on Abstract Interpre- Fault Conflict sets tation, a technique borrowed from program analy- Assumptions sis. The Abstract Interpretation mechanism is inte- grated with a classical model-based reasoning en- MBSD Engine gine. We test the approach on sample programs and provide the first experimental comparison with earlier models used for debugging. The results Diagnoses show that the Abstract Interpretation based model provides more precise explanations than previous Figure 1: MBSD cycle models or standard non-model based approaches. 2 Model-based debugging 1 Introduction Model-based software debugging (MBSD) is an application of Model-based Diagnosis (MBD) [19] techniques to locat- Developing tools to support the software engineer in locating ing errors in computer programs. MBSD was first intro- bugs in programs has been an active research area during the duced by Console et. al. [6], with the goal of identifying last decades, as increasingly complex programs require more incorrect clauses in logic programs; the approach has since and more effort to understand and maintain them. Several dif- been extended to different programming languages, includ- ferent approaches have been developed, using syntactic and ing VHDL [10] a n d JAVA [21]. semantic properties of programs and languages. The basic principle of MBD is to compare a model,ade- This paper extends past research on model-based diagnosis scription of the correct behaviour of a system, to the observed of mainstream object oriented languages, with Java as con- behaviour of the system. Traditional MBD systems receive crete example [14]. We show how abstract program anal- the description of the observed behaviour through direct mea- ysis techniques can be used to improve accuracy of results surements while the model is supplied by the system’s de- to a level well beyond the capabilities of past modelling ap- signer. The difference between the behaviour anticipated by proaches. In particular, we discuss adaptive model refine- the model and the actual observed behaviour is used to iden- ment. Our model refinement process targets loops in partic- tify components that, when assumed to deviate from their nor- ular, as those have been identified as the main culprits for mal behaviour, may explain the observed behaviour. imprecise diagnostic results. We exploit the information ob- The key idea of adapting MBD for debugging is to ex- tained from abstract program analysis to generate a refined change the roles of the model and the actual system: the model, which allows for more detailed reasoning and conflict model reflects the behaviour of the (incorrect) program, while detection. the test cases specify the correct result. Differences between Section 2 provides an introduction to model-based diag- the values computed by the program and the anticipated re- nosis and its application to automatic debugging. Section 3 sults are used to compute model elements that, when assumed outlines the adaption of the program analysis module of our to behave differently, explain the observed misbehaviour. The debugger and discusses differences between our and the clas- program’s instructions are partitioned into a set of model com- sical analysis frameworks. Section 4 contains results obtained ponents which form the building blocks of explanations. Each though a series of experiments and compares the outcome component corresponds to a fragment of the program’s source with other techniques. A discussion of related and future text, and diagnoses can be expressed in terms of the original work concludes the paper. program to indicate a potential fault to the programmer (see IJCAI-07 471 Figure 1). I : n → 4 Each component can operate in normal mode, denoted 1 int i =1 ¬AB (·), where the component functions as specified in the 2 int x =1 program, or in one or more abnormal modes, denoted AB (·), 3 while (i ≤ n) { with different behaviour. Intuitively, each component mode 4 x = x + i “ correct is x = x ∗ i ” corresponds to a particular modification of the program. 5 i = i +1 6 } Example 1 The program in Figure 2 can be partitioned into five components, C1,...,C5, each representing a sin- O : assert (x == 24) gle statement. For components representing assignments, a possible AB mode is to leave the variable’s value undeter- Figure 2: Example program and test specification mined. Another possibility is to expand the assignment to a set of variables, rendering their values undetermined. For C loops, the number of iterations could be altered. Example 2 Assume component 1 representing line 1 of the program in Figure 2 is abnormal. In this case, there is no ex- The model components, a formal description of the seman- ecution that terminates in a state satisfying x == 24.There- tics of the programming language and a set of test cases are fore, a fault in line 1 cannot explain the program’s misbe- submitted to the conformance testing module to determine haviour. In contrast, if the value of x is left undetermined if the program reflecting the fault assumptions is consistent after line 2, an execution exists where the program satisfies with the test cases. A program is found consistent with a test the assertion. Therefore, C2 is a potential explanation. case specification if the program possibly satisfies behaviour specified by the test case. While the definition of an explanation is intuitive, the pre- In case the program does not compute the anticipated re- cise test is undecidable and must be approximated. Differ- sult, the MBSD engine computes possible explanations in ent abstractions have been proposed in the literature, ranging terms of mode assignments to components and invokes the from purely dependency-based representations [10] to Pred- conformance testing module to determine if an explanation is icate Abstraction [13]. The following section introduces an indeed valid. This process iterates until one (or all) possible approximation based on Abstract Interpretation [8], a tech- explanations have been found. nique borrowed from program analysis. Formally, our MBSD framework is based on Reiter’s the- ory of diagnosis [19], extended to handle multiple fault modes 3 Model construction for a component. MBSD relies on test case specifications to Models developed for VHDL and early models for Java were determine if a set of fault represents is a valid explanation, based on static analysis and represented the program as a where each test case describes the anticipated result for an fixed model representing the program’s structure. As test execution using specific input values. cases were not taken into account, it was necessary to repre- Definition 1 (Debugging Problem) A Debugging Problem sent all possible executions and fault assumptions. While this is a triple P, T, C where P is the source text of the pro- approach has been used successfully to debug VHDL pro- gram under consideration, T is a set of test cases, and C grams, the dynamic method lookup and exception handling denotes the set of components derived from P . lead to large models for Java programs. Mayer and Stumptner [15] propose an approach where C P The set is a partition of all statements in and contains the model is constructed dynamically, taking into account the building blocks for explanations returned by the debugger. only executions that are feasible given a test case. The ap- For simplicity of presentation, it is assumed that there is a proach is based on Abstract Interpretation [8] of programs, separate component for each program statement. generalised to take fault assumptions and test case informa- A set of fault assumptions Δ =ˆ tion into account. In the following, the basic principles are {AB (C1) ,...,AB (Ck)} is a valid explanation if the introduced. More detailed presentations are given in [15; model modified such that components Ci may exhibit 16]. deviating behaviour, while the remaining components exhibit normal behaviour, no longer implies incorrect behaviour. 3.1 Abstract interpretation Definition 2 (Explanation) A fault assumption Δ is a con- The model is derived from a graph representing the effects of sistent explanation for a Debugging Problem P, T, C iff for individual statements of the program. alltestcasesT ∈ T, it cannot be derived that all executions P Δ T Definition 3 (Program Graph) A program graph for a pro- of (altered to reflect ) violate : gram P is a tuple V,S,Sω, E where V is a finite set of ∀T =ˆ I,O∈T [[ P ⊕ Δ ⊕ O]] ( I) = ⊥. vertices, E ⊆ V × V a set of directed edges, and S ∈ V and Sω ∈ V denote distinct entry and exit vertices. I and O represent the input values and assertions describing The vertices of the program graph represent sets of program the correct output values specified in a test specification, re- states; the edges represent the effects of program instructions, spectively. [[ ·]] denotes the semantic function of the program- transforming sets of program states into new sets of states. ming language and the fault assumptions. ⊕ denotes the ap- The initial vertex is associated with the initial program state plication of the fault assumptions in Δ and test assertions O I described by the test specification. An execution of a pro- P ⊥ to . denotes an infeasible program state. gram starts in the initial state in S and proceeds following the IJCAI-07 472 S ˆ ˆ proximation of is computed such that the program is guar- S : n → 4 S = I ˆ anteed to terminate in a state in γ(Sω).