A Lightweight Approach for Program Analysis and Debugging

Program slicing techniques like static, dynamic and hybrid slicing are considered to be an effective aid in the areas of program analysis and debugging. The performance parameters of these techniques such as precision and execution overhead determine their efficiency and applicability. In the context of debugging a few bugs, the existing dynamic and hybrid approaches tend to be expensive in terms of high runtime overhead while static slicing approaches fail to be precise. In this paper, we present a tool called JDAS to simplify the tedious task of debugging. The tool provides an intuitive way for the user to specify a bug and helps in efficient debugging by providing only the relevant information related to the bug being analyzed. We propose a lightweight approach for program analysis and debugging which is effective when the bugs to be analyzed are few. We make use of static slicing, which reduces the runtime cost and also helps in computing all the essential information including those which are not present in a dynamic slice as illustrated by the concept of relevant slicing. We harness the power of dynamic aspect oriented programming for effective tracing and thereby overcome the problem of imprecision in the slice result generated by static slicing. We introduce line number based pointcuts for efficient tracing.
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Lightweight Approach for Program Analysis andDebugging Rakesh M.G.* International Institute of Information Technology - Bangalore ABSTRACT Program slicing techniques like static, dynamic and hybridslicing are considered to be an effective aid in the areas of  program analysis and debugging. The performance parametersof these techniques such as precision and execution overheaddetermine their efficiency and applicability. In the context of debugging a few bugs, the existing dynamic and hybridapproaches tend to be expensive in terms of high runtimeoverhead and static slicing approaches fail to be precise.In this paper, we present a tool called JDAS to simplify thetedious task of debugging. The tool provides an intuitive way for the user to specify the bug and helps in efficient debugging by providing only the relevant information related to the bug beinganalyzed. We propose a lightweight approach for programanalysis and debugging which is effective when the bugs to beanalyzed are few. We make use of static slicing, which reducesthe runtime cost and also helps in computing all the essentialinformation including those which are not present in a dynamicslice as illustrated by the concept of relevant slicing. We harnessthe power of dynamic aspect oriented programming for effectivetracing and thereby overcome the problem of imprecision in theslice result generated by static slicing. We introduce linenumber based pointcuts for efficient tracing. Categories and Subject Descriptors D.2.5 [Testing and Debugging]: Debugging aids, tracing General Terms Design, Performance Keywords Java Debugger using Aspects and Slicing, JDAS, Line number  pointcuts, selective tracing 1.INTRODUCTION Program slicing has long been recognized as an effective meansof focusing attention on the relevant parts of a program.Program* The author is currently employed at SAP Labs India and is pursuing M.S. by Research at IIIT-Bangalore. slicing has been used widely in the areas of program debugging,testing, integration, software safety, software maintenance,software   metrics, reengineering, and parallelization approaches[6].Although, researchers have worked on a variety of slicingtechniques, there are only a few tools built which harness the power of slicing in the area of program debugging. Some of theimportant tools in this category are Whyline [13], JSlice [12, 23]and ADAS [19]. Each of these tools has their own strengths andlimitations in terms of either the slice computation or inrecording the execution trace.In this paper, we present a new kind of debugging tool calledJDAS 1 (stands for Java Debugger using Aspects and Slicing).JDAS is efficient in the context of debugging when thestatements involved in the analysis of the bugs span a smallfraction of the executed program code. For all practical purposes, this happens when we need to analyze few bugs 2 .Inour approach, we make use of static slicing for both control anddata dependencies. To address the problem of imprecision withstatic slice, we combine the slice result with the dynamicinformation collected during the program execution. In contrastto dynamic slicing techniques, in our approach there is no usageof dependence graph or costlier computations at runtime for obtaining the dependence information. The detailed comparisonof our approach with the existing tools can be found in Section 6of this paper.The main contributions of this paper are: (1) Proposal of anefficient approach to debug applications, when the bugs to beanalyzed are few (2) Illustrate how dynamic AOP can beeffectively applied in the areas of program analysis anddebugging (3) Introduction of line number based pointcuts andto demonstrate the usefulness of such pointcuts in the context of debugging.The remainder of this paper is organized as follows. In the restof this section, we briefly present a motivating example. Section2 gives an overview of program slicing and AOP. Section 3 presents an example to illustrate the usefulness of JDAS. InSection 4, we discuss on the design and implementation of JDAS. Section 5 presents experimental results. Related work is presented in Section 6 and Section 7 presents the limitations of our approach. Concluding remarks and future work is presentedin Section 8. 1 2 The interpretation of “few bugs” can be found in Section 5 of this paper. Permission to make digital or hard copies of all or part of this work for  personal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.  ISEC’10, Feb 25-27, 2010, Mysuru, Karnataka, India.Copyright 2010 ACM 978-1-60558-922-0/10/02.…$5.00  1.1Motivation In this section, we describe the problem that motivated us tocome up with a new approach amidst the existing tools andtechniques. Figure 1 illustrates a sales order applicationdeveloped using SWT (Standard Widget Toolkit) that displaysthe details of a particular sales order. The details of a sales order typically consists of the header information, list of items belonging to the sales order and the item details alongwith the pricing information. Figure 1. Sales Order Example The problem we are trying to investigate in this application isthat the net unit price of the selected item shown in the “ItemDetails” section seems to be incorrect. The net unit price of theitem is calculated by a complex pricing engine based on various parameters like list price, discounts, price breaks, surcharges,freight charges, taxes and so on. To debug this problem, oneneeds to analyze the statements affecting the net unit price alongwith the values of the variables to infer if the price modifiers arecorrectly applied.Once the bug is known, the statements’ affecting it is a fixedsubset of the entire application. It is sufficient for the buganalysis if these statements influencing the bug are selectivelytraced. Existing debugging tools like Whyline traces thecomplete execution information. In the above sales order example, it is not necessary to trace the statements which areirrelevant for the bug being analyzed. For example, recordingthe computation information for hundreds of items in the abovesales order example is irrelevant in the context of analyzing the problem with one item. Also, when the statements affecting the bug is a fixed subset of whole application, it is not necessary tocalculate the dependence information by analyzing the entireexecution trace at runtime as is the case with dynamic slicingtools like JSlice [23]. The user will have to pay the price of highruntime costs in terms of both memory consumed and timetaken to derive the information which is not useful for hisanalysis. In this paper, we propose an efficient way to cut downthis high runtime cost by reducing the redundancy in thecollected dynamic information with the help of static slicing anddynamic AOP. 2.PROGRAM SLICING and AOP2.1Program Slicing A slice S  ( v , n ) of program  P  on variable v , or set of variables, atstatement n yields the portions of the program that contributedto the value of  v just before statement n is executed. The tuple (v, n) is called the slicing criteria. Slices can be computed onsource programs by analyzing data flow and control flow.Slicing is done implicitly by programmers while debugging[16]. Slices can be combined to isolate sections of code likelyto contain program faults and significantly reduce debuggingtimes.Program slicing comes with many flavors based on factors like:static analysis or dynamic analysis (Static and Dynamic slicing),traversal direction used to compute dependencies (Backward andForward slicing), calculation within a procedure or across procedures (Intra-procedural and inter-procedural slicing). Thereare many variations of the slicing approaches like Weiser’s [15]srcinal approach of backward, static, intra-procedural slicingand Kamkar’s [14] backward, dynamic, inter-procedural slicing.There are also hybrid slicing approaches [18] which make use of the combination of static slicing and dynamic slicing. There isalso the concept of Relevant Slicing [1, 9]. A relevant slice withrespect to a variable contains not only the statements that havean influence on the variable but also those executed statementsthat did not affect the output, but could have affected it, hadthey been evaluated differently.Static slicing techniques use static analysis to derive slices. Thatis, the source code of the program is analyzed and the slices arecomputed for all possible input values. Therefore static slicescontain more statements than necessary and hence areconsidered to be of little use in the context of debugging.Korel and Laski [3] introduced the concept of dynamic programslicing. Dynamic slicing makes use of the information about a particular execution of a program. A dynamic slice with respectto a slicing criterion < s; V >, statement s and variable V for a particular execution, contains those statements that actuallyaffect the slicing criterion in the particular execution. Therefore,dynamic slices are usually smaller than static slices. 2.2AOP The goal of aspect-oriented programming (AOP) is to extractfunctionality that is scattered throughout the whole applicationsuch as logging, transaction management, or securitymanagement into a separate module [7]. The main entities inAOP are join points, pointcuts, advices and aspects. A join pointis a predictable point in the execution of an application (likemethod calls and exception handlers). Join points can be seen ashooks in a program where other program parts can beconditionally attached and executed. A pointcut is a structuredesigned to identify and select join points. Advice is the code to be executed when a join point is reached in the application code.Useful context information at the join point will be passed andmade available to the advice code. Aspect encapsulates the pointcuts and the advice.Separated crosscutting concerns encapsulated in a module aremerged into the srcinal system by a process called weaving.Weaving can be of two types, namely static weaving anddynamic weaving. In case of static weaving, the merging of aspect with the application code happens during the compiletime. The implementation approach can be either to use a pre-   processor or integrating the aspect weaver with the compiler.AspectJ [8] is an example for the AOP implementation based onstatic weaving. Merging the aspects into the application duringload time or runtime is called dynamic weaving. DynamicAspects 3  [5] and AspectWerkz [2] are examples AOPimplementations based on dynamic weaving. 3.EXAMPLE3.1The Debugging Process It is essential to understand the debugging process to verify if JDAS fulfils the desired functionality. Let us assume that a program  P  is executed with a test input  I  , and the program doesnot behave as it is expected to. How does a developer identifythe erroneous statements in the program code? Traditionally, thedeveloper debugs a program by examining a series of programstates, where these states are generated by executing program  P  with input  I  . The examination process continues until thedeveloper finds a location ‘ l  ’ of the execution, where the programstate before ‘ l  ’ is correct but the program state after ‘ l  ’ is wrong.The statements at the location ‘ l  ’ are indeed the buggystatements which should be fixed. However, the programexecution typically generates a large number of states, and eachstate consists of a lot of variables. It is impractical to manuallyexamine all the states for debugging. In practice, developershypothesize some locations which are likely to be the error, andonly examine program states around these locations. Ingeneral, the debugging process can besummarized as:Step 1: Hypothesize a location ‘ l  ’ which is likely to be the error,according to the developer’s understanding of the program.Step 2: Examine the states before/after ‘ l  ’ to determine whether the location ‘ l  ’ is indeed the error.During the debugging process, these two steps are repeated untilthe developer detects the erroneous statements. 3.2Using JDAS We will illustrate how JDAS can assist the user in the debugging process explained above with the sample sales order applicationshown in Figure 1. As stated in the motivation section of this paper, the problem with this application is the incorrect net unit price shown for the selected item in the item details view. Thefirst step in debugging this problem is to find out what parameters influence the value of net unit price. As describedearlier, the net unit price of an item is calculated based on thecustomer, discounts, price breaks (discounts based on the purchased quantity), surcharges, freight charges, tax, and specialcharges, if any. This activity of finding the parametersinfluencing the bug basically covers the first step in thedebugging process explained previously. Once the influencing parameters are identified, the next step is to answer thefollowing questions like: a) Was the discount correctlyconsidered? b) Did the purchased quantity qualify for the price break? c) Is the customer eligible for special discounts? and soon. Answering the above questions forms the second step in the 3 In this paper, usage of “Dynamic Aspects” (D and Acapitalized) refers to the aspect implementation itself [5],whereas “dynamic AOP” refers to the approach of weavingaspects into the application during the process of class loadingor runtime.debugging process. We will illustrate how JDAS can be used toanalyze this problem and answer the relevant questions.Using JDAS is a three step process:(1) Run the application using JDAS; perform the operations (if required) that resulted in the incorrect result. In our example, this refers to selecting the item which showsincorrect price from the list.(2) Select and register the criteria(3) Run the analyzer and examine the resultsIn the above example, the bug is the incorrect value displayed inthe label corresponding to the net unit price of the SWTapplication. This is the criteria input for JDAS. The user mapsthis criterion into the method “  setText(java.lang.String) ” of class “ org.eclipse.swt.widgets.Label  ”, which is responsible for setting value into the SWT label fields. But, there are manylabel fields in the GUI. How to communicate this to JDAS thatonly the net unit price label is the criteria? This is where thecriteria selector component of the JDAS comesto the rescue. Soon after the application is run using JDAS, thecriteria selector UI pops up as shown in Figure 2. Figure 2. Criteria selector In the criteria selector, user may select the UI element, whichshows incorrect behavior. From the “Members” tab, user can pick the members of the corresponding widget’s class whichcould have influenced the bug. In case of overloaded methods, if the user is not sure of the exact method, he can pick all of them, but only the executed methods during the current run will bechosen as the criteria. Once the criteria are chosen, JDAS willdo the task of finding all the statements in the program, whichmatch the selected criteria. In our example, this could be astatement containing the call to the method“ org.eclipse.swt.widgets.Label.setText(java.lang.String) ” on theselected Label object. In case of debugging an application whichhas terminated with an exception, the criteria selector component automatically picks the statement which caused theexception and registers it as the criteria.  Final step is to run the analyzer. This will trigger the JDAS’slicing engine to compute dependencies based on the registeredcriteria. JDAS’ slicing engine detects the suspicious locations byanalyzing the dependency chains between the erroneousstatements and the observable error. This is because, theerroneous statements affect the observable error via control flowand/or data flow. In fact, when a developer manually debugs,he/she will (manually) analyze the dependencies to understandhow the observable error is produced, thereby locating the realfault. Statements which do not appear in the dependency chainsdo (transitively) affect the observable error. These statementsare Figure 3. Using JDAS: (1) Starting point for the analysis is the Selected criteria view (2) Navigation using Data Dependees Viewto identify the problem (3) Source Files (4) JDAS editor highlighting the statements that were executed and also part of the slice(5) Control Dependees view (6) Before Variable Values view (7) After Variable Values view


Sep 9, 2017


Sep 9, 2017
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks