Locating causes of program failures

By Holger Cleve, Andreas Zeller. Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005., 2005

675 citations recorded by the source corpus.

Subfields: Information Systems, Software

View Paper: https://www.semanticscholar.org/paper/800e7956753ff5e32e28e1680936bcbd49b51c89

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Information Systems

In Software

Citations in the corpus

Statistical Debugging: A Hypothesis Testing-Based Approach (2006, background): “T HE last decade has witnessed great advances in fault localization techniques [1], [2], [3], [4], [5], [6], [7], [8], [9].”
A model for spectra-based software diagnosis (2011, methodology): “gives figures for Cause Transition (CT) from [Cleve and Zeller 2005].”
Locating faults through automated predicate switching (2006, methodology): “Therefore, program state based analysis is difﬁcult and time consuming for C programs [2].”
Learning to rank relevant files for bug reports using domain knowledge (2014, methodology): “Jin and Orso [16], Burger and Zeller [9], and Cleve and Zeller [11] use passing and failing execution information to locate buggy program entities.”
Empirical evaluation of the tarantula automatic fault-localization technique (2005, methodology): “Later, Cleve and Zeller [2] presented their technique, called Cause Transitions, compared it to the NearestNeighbor technique, and found that, on the same set of subjects, Cause Transitions consistently performs better than Nearest Neighbor (and thus set union and intersection tech-”
A Survey on Software Fault Localization (2016, background): “…using the ratio of the number of nodes in its smallest dependency sphere to the number of nodes in the entire PDG: The use of T-score requires that programmers are able to distinguish defects from non-defects at each location and can do so at the same cost for each location considered [77].”
Ask the Mutants: Mutating Faulty Programs for Fault Localization (2014, background): “However, they either partially depend on the conjectures of MUSE (some [2, 11, 34] in particular depend on the ﬁrst conjecture of MUSE) or rely on a different conjecture [9].”
Statistical debugging: simultaneous identification of multiple bugs (2006, methodology): “Starting from the top ranked predictor, we model the programmer as performing a breadth-ﬁrst search in the program dependence graph until reaching the buggy line(s) of code (Cleve & Zeller, 2005; Renieris & Reiss, 2003).”
SOBER: statistical model-based bug localization (2005, methodology): “Since we do not have detailed results from [5], CT is still only depicted at the 1, 10, and 20 ticks.”
BugFix: A learning-based tool to assist developers in fixing bugs (2009, background): “In the Delta Debugging framework, failure-inducing input is identified [33] that allows for the computation of cause-effect chains for failures [32] which can in turn be linked to faulty code [6].”
The DStar Method for Effective Software Fault Localization (2014, methodology): “Because it is not possible to theoretically prove if one fault localization technique shall always be more effective than another, such empirical validation is typically the norm for fault localization studies [1], [3], [8], [23], [25], [31], [39], [40], [42].”
HDD: hierarchical delta debugging (2006, methodology): “Delta Debugging the program state space is used as the mechanism for this technique [5,19].”
Metallaxis‐FL: mutation‐based fault localization (2015, methodology): “Another related approach which is not using coverage information is the Delta Debugging method [4], [5], [6].”