Fault localization with nearest neighbor queries

By Manos Renieris, Steven P. Reiss. 2003

782 citations recorded by the source corpus.

Subfields: Information Systems, Software

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

Improving Robot Controller Transparency Through Autonomous Policy Explanation (2017, methodology): “In order to resolve issues stemming from logical errors, automated debugging methods have been introduced [4, 3, 34] that seek to identify faulty program statements.”
Deep Code Search (2018, methodology): “Besides code search, there have been many other information retrieval tasks in software engineering [8, 9, 16, 23, 24, 29, 51, 55, 63, 67] such as bug localization [66, 73, 80], feature localization [19], traceability links recovery [20] and community Question Answering [11].”
Practitioners' expectations on automated fault localization (2016, background): “, [17, 38, 58], have received hundreds of citations mostly by papers proposing more recent techniques.”
Statistical Debugging: A Hypothesis Testing-Based Approach (2006, methodology): “Previously, many researchers investigating fault localization have reported their results on the Siemens suite [11], [20], [4], [6].”
Locating causes of program failures (2005, methodology): “However, applied to the Siemens suite, summarizing the coverage of failing runs either by intersection or union yields no useful results [11].”
Statistical debugging: simultaneous identification of multiple bugs (2006, methodology): “Starting from the top ranked predictor, we model the programmer as performing a breadth-first search in the program dependence graph until reaching the buggy line(s) of code (Cleve & Zeller, 2005; Renieris & Reiss, 2003 ).”
Are automated debugging techniques actually helping programmers? (2011, background): “Additional work in this area has investigated the use of clustering techniques to eliminate redundant executions and facilitate fault localization [10,13,18,21].”
BugFix: A learning-based tool to assist developers in fixing bugs (2009, background): “Nearest Neighbor [29] searches for a correct execution that is most similar to an incorrect execution, compares the spectra for these two executions, and identifies the most suspicious parts of the program.”
Retrieval from software libraries for bug localization: a comparative study of generic and composite text models (2011, background): “Dynamic analysis of a program relies on finding differences between the control flows of its passing and failing runs under certain input conditions [3] [22].”
On the Accuracy of Spectrum-based Fault Localization (2007, methodology): “The Nearest Neighbor technique first selects a single failed run, and computes the passed run that has the most similar code coverage.”
Empirical evaluation of the tarantula automatic fault-localization technique (2005, methodology): “We do this to compare the techniques fairly—only statements that can be represented in the SDG are considered.”
Locating faults through automated predicate switching (2006, background): “In contrast, Renieris and Reiss [12] focused on the difference between the failing run and a single passing run with similar spectra as a means to narrow down the search space for faulty code.”
Toward Semantic Foundations for Program Editors (2017, methodology): “mer, and those related toassertionfailuresorexceptionsencounteredwhenusingtheliveprogrammingfeatures of Hazel. In these situations, we plan to build on existing automated fault localization techniques[19,42,43]. Notethatfeatureslikethesearenotthemselvesnovel. Manyeditorsprovidecontextually relevants”
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].”
Spectrum-Based Multiple Fault Localization (2009, methodology): “SFL uses abstraction of program traces to correlate software component activity with program failures (a statistical approach) [4], [14], [20], [24], [29], [37].”
Ask the Mutants: Mutating Faulty Programs for Fault Localization (2014, methodology): “The traditional evaluation metric in SBFL literature is the Ex-pense metric, which is the percentage of program statements the human developer needs to inspect before encountering the faulty one [18].”