JOURNAL OF SOFTWARE, VOL. 8, NO. 3, MARCH 2013 603 Automated Breakpoint Generation for Debugging Cheng Zhang1;3, Juyuan Yang2, Dacong Yan4, Shengqian Yang4, Yuting Chen2 1Department of Computer Science & Engineering and 2School of Software, Shanghai Jiao Tong University 3State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences, Beijing, China 4Computer Science and Engineering Department, Ohio State University Email: [email protected], [email protected] fyan, [email protected], [email protected] Abstract— In debugging processes breakpoints are fre- for the subsequent debugging work. Some modern IDEs, quently used to inspect and understand the run-time pro- such as Eclipse1, provide the functionality to export and gram behavior. Although modern development environments import breakpoints, facilitating reuse and sharing of them. provide convenient breakpoint utilities, it mostly requires considerable human effort to create useful breakpoints. Additionally, we believe that breakpoints can also be Before setting a breakpoint or typing a breakpoint condition, automatically generated to further accelerate debugging developers usually have to make some judgements and processes. hypotheses based on their observations and experiences. To reduce the manual effort of debugging, researchers To reduce such kind of effort, we propose an approach have proposed a variety of automated debugging tech- to automatically generating breakpoints for debugging. We combine the nearest neighbor queries method, dynamic niques. Some techniques [5]–[8] focus on the abnor- program slicing, and memory graph comparison to identify mity of execution traces by collecting and analyzing suspicious program statements and states. Based on this the information of executions of the passing and failing information, breakpoints are generated and divided into test cases. Various measurements are taken to indicate two groups, where the primary group contains conditional the statements that are more relevant to failing runs breakpoints and the secondary group contains unconditional ones. We implement the presented approach on top of and identify the most relevant statements as the places the Eclipse JDT platform. Our objective experiments and where the faults reside. Another group of techniques put user study indicate that the generated breakpoints can be emphasis on the abnormal run-time program states [9]– effective in aiding debugging work. [11]. They observe the selected program states at certain Index Terms— software debugging, breakpoint generation locations and identify the most suspicious states which are much more likely to appear in failing runs. Ko and Myers [12] view the debugging process as a question I. INTRODUCTION and answer session and develop the innovative Whyline Debugging has long been a laborious task for software tool to prepare candidate questions and help to find developers [1], [2]. Despite the existence of various the answers by using both static and dynamic analysis automated debugging techniques, the practical debugging techniques. Nevertheless, developers may still encounter activities are mainly manual and interactive. It is difficult problems when using these techniques for real world to mechanically deal with diversified bugs, some of which debugging tasks. For example, they may want to try may be extremely tricky. Thus the fundamental tool in different techniques to find the fault more effectively. debugging is the human brain; the common debugging Then the problem is how they could use the outcomes process consists of several iterations of observing, making of different techniques. They may have to familiarize hypotheses, and testing the hypotheses [3]. themselves with various kinds of reports in the form of Most modern development environments provide com- tables of suspicious states, lists of faulty statements or prehensive utilities to aid debugging work. Among these some novel visualizations. Moreover, when the reports utilities, breakpoint is one of the most frequently used [4]. fail to indicate the faulty statements clearly, which is By using breakpoints developers can suspend the program often the case, developers probably have to switch to their execution and explore the program state to find clues to normal methods and make further effort to find the bugs. bugs. During the debugging process, however, developers In this case, they may need a seamless integration of the usually have to ask themselves a question: where to set the innovative techniques and the practical productivity tools. breakpoints? Setting breakpoints involves their observa- Thus it is helpful to improve the usability and the way tions, judgements and hypotheses on the current task and of combining automated debugging techniques to provide even experiences of similar situations. It is common that continuous support for debugging. a veteran sets a small number of breakpoints to reveal a In this paper, we propose a method to generate break- bug immediately, whereas a novice sets excessive useless points based on a synergy of existing fault localization breakpoints, but still fails to find the bug. Therefore, for a techniques. With regard to the typical situation of debug- developer, a set of well defined breakpoints presented in a familiar debugger may be a quite pleasant starting point 1http://www.eclipse.org/ © 2013 ACADEMY PUBLISHER doi:10.4304/jsw.8.3.603-616 604 JOURNAL OF SOFTWARE, VOL. 8, NO. 3, MARCH 2013 ging, where there are much fewer failing test cases than count spectra, how many times each basic block has been passing ones, we first use the nearest neighbor queries executed matters. Take the asymmetric Hamming distance method [6] to select a passing case that is the most (AHD) and binary coverage spectrum as an example. similar to the failing case (in terms of execution flow) and Binary coverage spectra are usually represented as binary compare them to find the suspicious basic blocks. Then vectors. Thus the Hamming distance between two runs we use backward dynamic slicing [13] to augment the f (failing run) and p (passing run) is defined as the report of the nearest neighbor queries in order to reveal number of positions at which the two representing binary the causes of the differences between the two execution vectors disagree. The asymmetric Hamming distance, flows. Line breakpoints are generated at the conditional which considers the non-symmetric difference f − p, is statements contained in the dynamic slices. At last we used to report features that are only present in the failing extract memory graphs at specific breakpoints, compare run f. A sample calculation is given in Table I. the graphs to identify the most interesting differences TABLE I. of program states, and generate breakpoint conditions AHD BETWEEN TWO RUNS, USING BINARY COVERAGE SPECTRA based on the state differences. The goal of our work is to automatically generate useful breakpoints to aid real sample Block 1 Block 2 Block 3 world debugging activities. We have performed a group Failing Run f 3 0 2 of objective experiments to show the effectiveness of Passing Run p 0 1 3 our technique in fault localization. In addition, we have Block Difference 1 0 0 Distance(f; p) = (1 + 0 + 0)=3 = 1=3 performed a user study to demonstrate the usefulness of our approach. When all the pairwise distances have been computed, An earlier version of the proposed approach has been the pair with the minimum distance value is selected and implemented and publicly demonstrated [14]. By com- compared. Finally, those basic blocks executed only in parison, this paper improves the step of breakpoint con- the failing run will be reported as suspicious. dition generation, making it more efficient and portable. Different from the tool demonstration paper [14], this B. Dynamic Program Slicing paper explains the key ideas with necessary background Program slicing was first introduced by Weiser [16] to (Section II) and a running example (Section III). Also, extract parts of program code corresponding to program this paper gives more detailed explanations on the con- behaviors of interest. Since then it has been widely siderations, strategies, algorithms, and trade-offs in our applied to program testing, debugging, understanding and approach (Section IV). In addition, a comprehensive eval- other maintenance activities. During program debugging it uation has been performed and the results are shown and can be used to reduce the amount of code developers need discussed extensively (Section VI). to inspect. In program slicing, a program is sliced with In summary, the main contributions of our work are: respect to a slicing criterion, hp; V i, where p is a specified • We propose the idea of automated breakpoint gen- program point and V is a set of variables of interest. eration by leveraging the power of fault localization The conventional program slicing is static, because it is techniques. This approach can be a viable way of performed based on static program dependencies and finds utilizing academic productions in practical debug- all the statements that might affect the slicing criterion. ging environments. Although being helpful to debugging, static program • We implement a prototype of our approach on top slicing often produces too large slices to reduce the de- of the Eclipse JDT platform and use it to perform velopers’ effort. In order to narrow down the search space objective experiments and case studies. The result further, Korel and Laski [13] proposed dynamic