1,036 research outputs found

    Integration of an Automatic Fault Localization Tool in an IDE and its Evaluation

    Get PDF
    Debugging is one of the most demanding and error-prone tasks in software development. Trying to address bugs has become overall more expensive as the software complexity and size have increased. As a result, several researchers attempted to improve the developers’ debugging experience and efficiency by automating as much of the process as possible. Existing auto-finding tools will assist developers in automatically detecting bugs, however, they are not yet widely available to software engineers. Making such tools available to developers can save debugging time and increase the productivity. Subsequently, the main goal of this dissertation is to incorporate an automatic fault localization tool into an Integrated Development Environment (IDE). The selected IDE was Visual Studio Code, a source-code editor developed by Microsoft for Windows, Linux, and macOS. Visual Studio Code is one of the most used IDEs and is known for its flexible API, which allows nearly every aspect of it to be customized. Furthermore, the chosen automatic fault localization tool was FLACOCO, a recent fault localization tool for Java that supports up to the most recent versions. Nonetheless, this document contains a full overview of several fault localization methodologies and tools, as well as an explanation of the complete planning and development process of the produced Visual Studio Code extension. After the development and deployment were completed, an evaluation was carried out. The extension was evaluated through a user study in which thirty Java professionals took part. The test had two parts: the first involved users using the extension to complete two debugging tasks in previously unknown projects, and the second had them filling out a satisfaction questionnaire for further analysis. Finally, the results show that the extension was a success, with the system being rated positively in all areas. However, it may be revised in light of the questionnaire responses, with the suggestions received being considered for future work.A depuração é uma das tarefas mais exigentes e propensas a erros no desenvolvimento de software. Tentar resolver esses erros tornou-se mais dispendioso com os incrementos de complexidade e tamanho do software. Deste modo, ao longo dos últimos anos, vários investigadores tentaram melhorar a experiência de depuração e a eficiência dos desenvolvedores automatizando o máximo possível do processo. Existem ferramentas de localização de defeitos que assistem os desenvolvedores na detecção automática de bugs, no entanto estas ainda não se encontram amplamente disponíveis para os programadores. Tornar essas ferramentas disponíveis para todos certamente iria resultar na redução do tempo de depuração e no aumento da produtividade. Assim sendo, o principal objetivo desta dissertação é incorporar uma ferramenta de localização automática de defeitos num IDE. Em termos de IDE, o Visual Studio Code, um editor de código-fonte desenvolvido pela Microsoft para Windows, Linux e macOS, foi selecionado. Este IDE tem ganho bastante popularidade, sendo um dos IDEs mais utilizados mundialmente. Além disso, o Visual Studio Code é reconhecido pela sua API flexível, que permite que quase todos os seus aspectos sejam personalizados. Adicionalmente, o FLACOCO, uma ferramenta de localização de defeitos baseada em SFL que suporta até as versões mais recentes do Java, foi escolhida como ferramenta de localização automática de defeitos. Além do mais, esta dissertação contém um estudo sobre as técnicas de localização automática de defeitos e as suas ferramentas, bem como uma explicação do planeamento e implementação da extensão criada para o Visual Studio Code. Após o término da implementação e a posterior implantação, foi efetuada a sua avaliação. Procedeu-se a um teste de utilização com a participação de treze utilizadores proficientes na linguagem Java. O teste foi composto por duas componentes: na primeira os utilizadores utilizaram a extensão para completar duas tarefas de depuração em projetos por eles desconhecidos e na segunda foi-lhes fornecido um questionário de satisfação para posterior análise. Os resultados obtidos sugerem que a extensão foi um sucesso, sendo que o sistema foi positivamente avaliado em todos os aspetos. No entanto a mesma poderá ser aprimorada tendo em consideração o feedback obtido na secção de resposta livre do questionário, sendo que o mesmo foi bastante valioso e as sugestões apuradas vieram a ser consideradas para trabalho futuro

    Reproducing Failures in Fault Signatures

    Full text link
    Software often fails in the field, however reproducing and debugging field failures is very challenging: the failure-inducing input may be missing, and the program setup can be complicated and hard to reproduce by the developers. In this paper, we propose to generate fault signatures from the failure locations and the original source code to reproduce the faults in small executable programs. We say that a fault signature reproduces the fault in the original program if the two failed in the same location, triggered the same error conditions after executing the same selective sequences of failure-inducing statements. A fault signature aims to contain only sufficient statements that can reproduce the faults. That way, it provides some context to inform how a fault is developed and also avoids unnecessary complexity and setups that may block fault diagnosis. To compute fault signatures from the failures, we applied a path-sensitive static analysis tool to generate a path that leads to the fault, and then applied an existing syntactic patching tool to convert the path into an executable program. Our evaluation on real-world bugs from Corebench, BugBench, and Manybugs shows that fault signatures can reproduce the fault for the original programs. Because fault signatures are less complex, automatic test input generation tools generated failure-inducing inputs that could not be generated by using the entire programs. Some failure-inducing inputs can be directly transferred to the original programs. Our experimental data are publicly available at https://doi.org/10.5281/zenodo.5430155

    Locating Faults with Program Slicing: An Empirical Analysis

    Get PDF
    Statistical fault localization is an easily deployed technique for quickly determining candidates for faulty code locations. If a human programmer has to search the fault beyond the top candidate locations, though, more traditional techniques of following dependencies along dynamic slices may be better suited. In a large study of 457 bugs (369 single faults and 88 multiple faults) in 46 open source C programs, we compare the effectiveness of statistical fault localization against dynamic slicing. For single faults, we find that dynamic slicing was eight percentage points more effective than the best performing statistical debugging formula; for 66% of the bugs, dynamic slicing finds the fault earlier than the best performing statistical debugging formula. In our evaluation, dynamic slicing is more effective for programs with single fault, but statistical debugging performs better on multiple faults. Best results, however, are obtained by a hybrid approach: If programmers first examine at most the top five most suspicious locations from statistical debugging, and then switch to dynamic slices, on average, they will need to examine 15% (30 lines) of the code. These findings hold for 18 most effective statistical debugging formulas and our results are independent of the number of faults (i.e. single or multiple faults) and error type (i.e. artificial or real errors)

    Assessing the Effectiveness of Defect Prediction-based Test Suites at Localizing Faults

    Get PDF
    Debugging a software program constitutes a significant and laborious task for programmers, often consuming a substantial amount of time. The need to identify faulty lines of code further compounds this challenge, leading to decreased overall productivity. Consequently, the development of automated tools for fault detection becomes imperative to streamline the debugging process and enhance programmer productivity. In recent years, the field of automatic test generation has witnessed remarkable advancements, significantly improving the efficacy of automatic tests in detecting faults. The localization of faults can be further optimized through the utilization of such sophisticated tools. This dissertation aims to conduct an experimental study that assembles specialized automatic test generation tools designed to detect faults by estimating the likelihood of code being faulty. These tools will be compared against each other to discern their relative performance and effectiveness. Additionally, the study will comprehensively compare developer-generated tests with automatically generated tests to evaluate their respective aptitude for fault detection. Through this investigation, we seek to identify the most effective automated test generation tool while providing valuable insights into the relative merits of developer-generated and automatically generated tests for fault detection

    Automated Failure Explanation Through Execution Comparison

    Get PDF
    When fixing a bug in software, developers must build an understanding or explanation of the bug and how the bug flows through a program. The effort that developers must put into building this explanation is costly and laborious. Thus, developers need tools that can assist them in explaining the behavior of bugs. Dynamic slicing is one technique that can effectively show how a bug propagates through an execution up to the point where a program fails. However, dynamic slices are large because they do not just explain the bug itself; they include extra information that explains any observed behavior that might be connected to the bug. Thus, the explanation of the bug is hidden within this other tangentially related information. This dissertation addresses the problem and shows how a failing execution and a correct execution may be compared in order to construct explanations that include only information about what caused the bug. As a result, these automated explanations are significantly more concise than those explanations produced by existing dynamic slicing techniques. To enable the comparison of executions, we develop new techniques for dynamic analyses that identify the commonalities and differences between executions. First, we devise and implement the notion of a point within an execution that may exist across multiple executions. We also note that comparing executions involves comparing the state or variables and their values that exist within the executions at different execution points. Thus, we design an approach for identifying the locations of variables in different executions so that their values may be compared. Leveraging these tools, we design a system for identifying the behaviors within an execution that can be blamed for a bug and that together compose an explanation for the bug. These explanations are up to two orders of magnitude smaller than those produced by existing state of the art techniques. We also examine how different choices of a correct execution for comparison can impact the practicality or potential quality of the explanations produced via our system

    Break the dead end of dynamic slicing: localizing data and control omission bug

    Get PDF
    Dynamic slicing is a common way of identifying the root cause when a program fault is revealed. With the dynamic slicing technique, the programmers can follow data and control flow along the program execution trace to the root cause. However, the technique usually fails to work on omission bugs, i.e., the faults which are caused by missing executing some code. In many cases, dynamic slicing over-skips the root cause when an omission bug happens, leading the debugging process to a dead end. In this work, we conduct an empirical study on the omission bugs in the Defects4J bug repository. Our study shows that (1) omission bugs are prevalent (46.4%) among all the studied bugs; (2) there are repeating patterns on causes and fixes of the omission bugs; (3) the patterns of fixing omission bugs serve as a strong hint to break the slicing dead end. Based on our findings, we train a neural network model on the omission bugs in Defects4J repository to recommend where to approach when slicing can no long work. We conduct an experiment by applying our approach on 3193 mutated omission bugs which slicing fails to locate. The results show that our approach outperforms random benchmark on breaking the dead end and localizing the mutated omission bugs (63.8% over 2.8%).No Full Tex
    corecore