Results 1 - 10
of
234
Locating causes of program failures
- 27th International Conference on Software Engineering (ICSE
, 2005
"... Which is the defect that causes a software failure? By comparing the program states of a failing and a passing run, we can identify the state differences that cause the failure. However, these state differences can occur all over the program run. Therefore, we focus in space on those variables and v ..."
Abstract
-
Cited by 235 (9 self)
- Add to MetaCart
(Show Context)
Which is the defect that causes a software failure? By comparing the program states of a failing and a passing run, we can identify the state differences that cause the failure. However, these state differences can occur all over the program run. Therefore, we focus in space on those variables and values that are relevant for the failure, and in time on those moments where cause transitions occur—moments where new relevant variables begin being failure causes: “Initially, variable argc was 3; therefore, at shell sort(), variable a[2] was 0, and therefore, the program failed. ” In our evaluation, cause transitions locate the failureinducing defect twice as well as the best methods known so far.
Empirical evaluation of the tarantula automatic fault-localization technique
- in Proceedings of the IEEE/ACM International Conference on Automated Software Engineering
, 2005
"... The high cost of locating faults in programs has motivated the development of techniques that assist in fault localization by automating part of the process of searching for faults. Empirical studies that compare these techniques have reported the relative effectiveness of four existing techniques o ..."
Abstract
-
Cited by 235 (8 self)
- Add to MetaCart
(Show Context)
The high cost of locating faults in programs has motivated the development of techniques that assist in fault localization by automating part of the process of searching for faults. Empirical studies that compare these techniques have reported the relative effectiveness of four existing techniques on a set of subjects. These studies compare the rankings that the techniques compute for statements in the subject programs and the effectiveness of these rankings in locating the faults. However, it is unknown how these four techniques compare with Tarantula, another existing fault-localization technique, although this technique also provides a way to rank statements in terms of their suspiciousness. Thus, we performed a study to compare the Tarantula technique with the four techniques previously compared. This paper presents our study—it overviews the Tarantula technique along with the four other techniques studied, describes our experiment, and reports and discusses the results. Our studies show that, on the same set of subjects, the Tarantula technique consistently outperforms the other four techniques in terms of effectiveness in fault localization, and is comparable in efficiency to the least expensive of the other four techniques.
Sober: statistical model-based bug localization
- In Proc. ESEC/FSE’05
, 2005
"... Automated localization of software bugs is one of the es-sential issues in debugging aids. Previous studies indicated that the evaluation history of program predicates may dis-close important clues about underlying bugs. In this paper, we propose a new statistical model-based approach, called SOBER, ..."
Abstract
-
Cited by 144 (12 self)
- Add to MetaCart
(Show Context)
Automated localization of software bugs is one of the es-sential issues in debugging aids. Previous studies indicated that the evaluation history of program predicates may dis-close important clues about underlying bugs. In this paper, we propose a new statistical model-based approach, called SOBER, which localizes software bugs without any prior knowledge of program semantics. Unlike existing statisti-cal debugging approaches that select predicates correlated with program failures, SOBER models evaluation patterns of predicates in both correct and incorrect runs respectively and regards a predicate as bug-relevant if its evaluation pat-tern in incorrect runs differs significantly from that in correct ones. SOBER features a principled quantification of the pat-tern difference that measures the bug-relevance of program predicates. We systematically evaluated our approach under the same setting as previous studies. The result demonstrated the power of our approach in bug localization: SOBER can help programmers locate 68 out of 130 bugs in the Siemens suite when programmers are expected to examine no more than 10 % of the code, whereas the best previously reported is 52 out of 130. Moreover, with the assistance of SOBER, we found two bugs in bc 1.06 (an arbitrary precision calcula-tor on UNIX/Linux), one of which has never been reported before.
Error Explanation with Distance Metrics
- In Tools and Algorithms for the Construction and Analysis of Systems
, 2004
"... In the event that a system does not satisfy a speci cation, a model checker will typically automatically produce a counterexample trace that shows a particular instance of the undesirable behavior. ..."
Abstract
-
Cited by 87 (8 self)
- Add to MetaCart
(Show Context)
In the event that a system does not satisfy a speci cation, a model checker will typically automatically produce a counterexample trace that shows a particular instance of the undesirable behavior.
A Novel Co-evolutionary Approach to Automatic Software Bug Fixing
- In Proceedings of the IEEE Congress on Evolutionary Computation (CEC ’08
, 2008
"... expensive, and that has led the investigation to how to automate them. In particular, Software Testing can take up to half of the resources of the development of new software. Although there has been a lot of work on automating the testing phase, fixing a bug after its presence has been discovered i ..."
Abstract
-
Cited by 81 (8 self)
- Add to MetaCart
(Show Context)
expensive, and that has led the investigation to how to automate them. In particular, Software Testing can take up to half of the resources of the development of new software. Although there has been a lot of work on automating the testing phase, fixing a bug after its presence has been discovered is still a duty of the programmers. In this paper we propose an evolutionary approach to automate the task of fixing bugs. This novel evolutionary approach is based on Co-evolution, in which programs and test cases co-evolve, influencing each other with the aim of fixing the bugs of the programs. This competitive co-evolution is similar to what happens in nature for predators and prey. The user needs only to provide a buggy program and a formal specification of it. No other information is required. Hence, the approach may work for any implementable software. We show some preliminary experiments in which bugs in an implementation of a sorting algorithm are automatically fixed. I.
Locating faulty code using failure-inducing chops
- In 20th IEEE/ACM International Conference on Automated Software Engineering (ASE 2005
, 2005
"... Software debugging is the process of locating and correcting faulty code. Prior techniques to locate faulty code either use program analysis techniques such as backward dynamic program slicing or exclusively use delta debugging to analyze the state changes during program execution. In this paper, we ..."
Abstract
-
Cited by 73 (11 self)
- Add to MetaCart
(Show Context)
Software debugging is the process of locating and correcting faulty code. Prior techniques to locate faulty code either use program analysis techniques such as backward dynamic program slicing or exclusively use delta debugging to analyze the state changes during program execution. In this paper, we present a new approach that integrates the potential of delta debugging algorithm with the benefit of forward and backward dynamic program slicing to narrow down the search for faulty code. Our approach is to use delta debugging algorithm to identify a minimal failure-inducing input, use this input to compute a forward dynamic slice and then intersect the statements in this forward dynamic slice with the statements in the backward dynamic slice of the erroneous output to compute a failure-inducing chop. We implemented our technique and conducted experiments with faulty versions of several programs from the Siemens suite to evaluate our technique. Our experiments show that failure-inducing chops can greatly reduce the size of search space compared to the dynamic slices without significantly compromising the capability to locate the faulty code. We also applied our technique to several programs with known memory related bugs such as buffer overflow bugs. The failure-inducing chop in several of these cases contained only 2 to 4 statements which included the code causing memory corruption.
Automated Known Problem Diagnosis with Event Traces
- In EuroSys
, 2006
"... Computer problem diagnosis remains a serious challenge to users and support professionals. Traditional troubleshooting methods relying heavily on human intervention make the process inefficient and the results inaccurate even for solved problems, which contribute significantly to user’s dissatisfact ..."
Abstract
-
Cited by 64 (6 self)
- Add to MetaCart
(Show Context)
Computer problem diagnosis remains a serious challenge to users and support professionals. Traditional troubleshooting methods relying heavily on human intervention make the process inefficient and the results inaccurate even for solved problems, which contribute significantly to user’s dissatisfaction. We propose to use system behavior information such as system event traces to build correlations with solved problems, instead of using only vague text descriptions as in existing practices. The goal is to enable automatic identification of the root cause of a problem if it is a known one, which would further lead to its resolution. By applying statistical learning techniques to classifying system call sequences, we show our approach can achieve considerable accuracy of root cause recognition by studying four case examples.
Holmes: Effective statistical debugging via efficient path profiling
- IN 31ST INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE 2009
, 2009
"... Statistical debugging aims to automate the process of isolating bugs by profiling several runs of the program and using statistical analysis to pinpoint the likely causes of failure. In this paper, we investigate the impact of using richer program profiles such as path profiles on the effectiveness ..."
Abstract
-
Cited by 63 (3 self)
- Add to MetaCart
(Show Context)
Statistical debugging aims to automate the process of isolating bugs by profiling several runs of the program and using statistical analysis to pinpoint the likely causes of failure. In this paper, we investigate the impact of using richer program profiles such as path profiles on the effectiveness of bug isolation. We describe a statistical debugging tool called HOLMES that isolates bugs by finding paths that correlate with failure. We also present an adaptive version of HOLMES that uses iterative, bug-directed profiling to lower execution time and space overheads. We evaluate HOLMES using programs from the SIR benchmark suite and some large, real-world applications. Our results indicate that path profiles can help isolate bugs more precisely by providing more information about the context in which bugs occur. Moreover, bug-directed profiling can efficiently isolate bugs with low overheads, providing a scalable and accurate alternative to sparse random sampling.
Statistical debugging: A hypothesis testing-based approach
- IEEE TRANSACTION ON SOFTWARE ENGINEERING
, 2006
"... Manual debugging is tedious, as well as costly. The high cost has motivated the development of fault localization techniques, which help developers search for fault locations. In this paper, we propose a new statistical method, called SOBER, which automatically localizes software faults without any ..."
Abstract
-
Cited by 59 (6 self)
- Add to MetaCart
(Show Context)
Manual debugging is tedious, as well as costly. The high cost has motivated the development of fault localization techniques, which help developers search for fault locations. In this paper, we propose a new statistical method, called SOBER, which automatically localizes software faults without any prior knowledge of the program semantics. Unlike existing statistical approaches that select predicates correlated with program failures, SOBER models the predicate evaluation in both correct and incorrect executions and regards a predicate as fault-relevant if its evaluation pattern in incorrect executions significantly diverges from that in correct ones. Featuring a rationale similar to that of hypothesis testing, SOBER quantifies the fault relevance of each predicate in a principled way. We systematically evaluate SOBER under the same setting as previous studies. The result clearly demonstrates the effectiveness: SOBER could help developers locate 68 out of the 130 faults in the Siemens suite by examining no more than 10 percent of the code, whereas the Cause Transition approach proposed by Holger et al. [6] and the statistical approach by Liblit et al. [12] locate 34 and 52 faults, respectively. Moreover, the effectiveness of SOBER is also evaluated in an “imperfect world,” where the test suite is either inadequate or only partially labeled. The experiments indicate that SOBER could achieve competitive quality under these harsh circumstances. Two case studies with grep 2.2 and bc 1.06 are reported, which shed light on the applicability of SOBER on reasonably large programs.
Fault localization using value replacement
- International Symposium on Software Testing and Analysis
, 2008
"... We present a value profile based approach for ranking program statements according to their likelihood of being faulty. The key idea is to see which program statements exercised during a failing run use values that can be altered so that the execution instead produces correct output. Our approach is ..."
Abstract
-
Cited by 59 (5 self)
- Add to MetaCart
(Show Context)
We present a value profile based approach for ranking program statements according to their likelihood of being faulty. The key idea is to see which program statements exercised during a failing run use values that can be altered so that the execution instead produces correct output. Our approach is effective in locating statements that are either faulty or directly linked to a faulty statement. We present experimental results showing the effectiveness and efficiency of our approach. Our approach outperforms Tarantula [9] which, to our knowledge, is the most effective prior approach for statement ranking based fault localization using the benchmark programs we studied.
