The Experts below are selected from a list of 1881 Experts worldwide ranked by ideXlab platform
Martin Monperrus - One of the best experts on this subject based on the ideXlab platform.
-
Production-Driven Patch Generation
2017Co-Authors: Thomas Durieux, Youssef Hamadi, Martin MonperrusAbstract:We present an original concept for patch generation: we propose to do it directly in production. Our idea is to generate patches on-the-fly based on automated analysis of the failure context. By doing this in production, the repair process has complete access to the system state at the point of failure. We propose to perform live regression Testing of the generated patches directly on the production traffic, by feeding a sandboxed version of the application with a copy of the production traffic, the “shadow traffic”. Our concept widens the applicability of program repair, because it removes the requirements of having a Failing Test Case.
-
ICSE-NIER - Production-driven patch generation
2017 IEEE ACM 39th International Conference on Software Engineering: New Ideas and Emerging Technologies Results Track (ICSE-NIER), 2017Co-Authors: Thomas Durieux, Youssef Hamadi, Martin MonperrusAbstract:We present an original concept for patch generation: we propose to do it directly in production. Our idea is to generate patches on-the-fly based on automated analysis of the failure context. By doing this in production, the repair process has complete access to the system state at the point of failure. We propose to perform live regression Testing of the generated patches directly on the production traffic, by feeding a sandboxed version of the application with a copy of the production traffic, the "shadow traffic". Our concept widens the applicability of program repair, because it removes the requirements of having a Failing Test Case.
-
Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset
Empirical Software Engineering, 2016Co-Authors: Matias Martinez, Thomas Durieux, Jifeng Xuan, Romain Sommerard, Martin MonperrusAbstract:Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J comes with a Test suite and at least one Failing Test Case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic Test-suite based repair on Defects4J. The result of our experiment shows that the considered state-of-the-art repair methods can generate patches for 47 out of 224 bugs. However, those patches are only Test-suite adequate, which means that they pass the Test suite and may potentially be incorrect beyond the Test-suite satisfaction correctness criterion. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly repaired with Test-suite based repair. This analysis shows that Test-suite based repair suffers from under-specified bugs, for which trivial or incorrect patches still pass the Test suite. With respect to practical applicability, it takes on average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All the repair systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.
-
Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs
IEEE Transactions on Software Engineering, 2016Co-Authors: Jifeng Xuan, M. Martinez, Favio Demarco, Maxime Clement, Sebastian R. Lamelas Marcote, Thomas Durieux, Daniel Le Berre, Martin MonperrusAbstract:We propose Nopol , an approach to automatic repair of buggy conditional statements (i.e., if-then-else statements). This approach takes a buggy program as well as a Test suite as input and generates a patch with a conditional expression as output. The Test suite is required to contain passing Test Cases to model the expected behavior of the program and at least one Failing Test Case that reveals the bug to be repaired. The process of Nopol consists of three major phases. First, Nopol employs angelic fix localization to identify expected values of a condition during the Test execution. Second, runtime trace collection is used to collect variables and their actual values, including primitive data types and objected-oriented features (e.g., nullness checks), to serve as building blocks for patch generation. Third, Nopol encodes these collected data into an instance of a Satisfiability Modulo Theory (SMT) problem; then a feasible solution to the SMT instance is translated back into a code patch. We evaluate Nopol on 22 real-world bugs (16 bugs with buggy if conditions and six bugs with missing preconditions) on two large open-source projects, namely Apache Commons Math and Apache Commons Lang. Empirical analysis on these bugs shows that our approach can effectively fix bugs with buggy if conditions and missing preconditions. We illustrate the capabilities and limitations of Nopol using Case studies of real bug fixes.
-
On Oracles for Automated Diagnosis and Repair of Software Bugs
2016Co-Authors: Martin MonperrusAbstract:This HDR focuses on my work on automatic diagnosis and repair done over the past years. Among my past publications, it highlights three contributions on this topic, respectively published in ACM Transactions on Software Engineering and Methodology (TOSEM), IEEE Transactions on Software Engineering (TSE) and Elsevier Information & Software Technology (IST). My goal is to show that those three contributions share something deep, that they are founded on a unifying concept, which is the one of oracle. The first contribution is about statistical oracles. In the context of object-oriented software, we have defined a notion of context and normality that is specific to a fault class: missing method calls. Those inferred regularities act as oracle and their violations are considered as bugs. The second contribution is about Test Case based oracles for automatic repair. We describe an automatic repair system that fixes Failing Test Cases by generating a patch. It is founded on the idea of refining the knowledge given by the violation of the oracle of the Failing Test Case into finer-grain information, which we call a “micro-oracle”. By considering micro-oracles, we are capable of obtaining at the same time a precise fault localization diagnostic and a well-formed input-output specification to be used for program synthesis in order to repair a bug. The third contribution discusses a novel generic oracle in the context of exception handling. A generic oracle states properties that hold for many domains. Our technique verifies the compliance to this new oracle using Test suite execution and exception injection. This document concludes with a research agenda about the future of engineering ultra-dependable and antifragile software systems.
Jifeng Xuan - One of the best experts on this subject based on the ideXlab platform.
-
Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset
Empirical Software Engineering, 2016Co-Authors: Matias Martinez, Thomas Durieux, Jifeng Xuan, Romain Sommerard, Martin MonperrusAbstract:Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J comes with a Test suite and at least one Failing Test Case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic Test-suite based repair on Defects4J. The result of our experiment shows that the considered state-of-the-art repair methods can generate patches for 47 out of 224 bugs. However, those patches are only Test-suite adequate, which means that they pass the Test suite and may potentially be incorrect beyond the Test-suite satisfaction correctness criterion. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly repaired with Test-suite based repair. This analysis shows that Test-suite based repair suffers from under-specified bugs, for which trivial or incorrect patches still pass the Test suite. With respect to practical applicability, it takes on average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All the repair systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.
-
Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs
IEEE Transactions on Software Engineering, 2016Co-Authors: Jifeng Xuan, M. Martinez, Favio Demarco, Maxime Clement, Sebastian R. Lamelas Marcote, Thomas Durieux, Daniel Le Berre, Martin MonperrusAbstract:We propose Nopol , an approach to automatic repair of buggy conditional statements (i.e., if-then-else statements). This approach takes a buggy program as well as a Test suite as input and generates a patch with a conditional expression as output. The Test suite is required to contain passing Test Cases to model the expected behavior of the program and at least one Failing Test Case that reveals the bug to be repaired. The process of Nopol consists of three major phases. First, Nopol employs angelic fix localization to identify expected values of a condition during the Test execution. Second, runtime trace collection is used to collect variables and their actual values, including primitive data types and objected-oriented features (e.g., nullness checks), to serve as building blocks for patch generation. Third, Nopol encodes these collected data into an instance of a Satisfiability Modulo Theory (SMT) problem; then a feasible solution to the SMT instance is translated back into a code patch. We evaluate Nopol on 22 real-world bugs (16 bugs with buggy if conditions and six bugs with missing preconditions) on two large open-source projects, namely Apache Commons Math and Apache Commons Lang. Empirical analysis on these bugs shows that our approach can effectively fix bugs with buggy if conditions and missing preconditions. We illustrate the capabilities and limitations of Nopol using Case studies of real bug fixes.
-
CSTVA - Automatic repair of buggy if conditions and missing preconditions with SMT
Proceedings of the 6th International Workshop on Constraints in Software Testing Verification and Analysis - CSTVA 2014, 2014Co-Authors: Favio Demarco, Jifeng Xuan, Daniel Le Berre, Martin MonperrusAbstract:We present Nopol, an approach for automatically repairing buggy if conditions and missing preconditions. As input, it takes a program and a Test suite which contains passing Test Cases modeling the expected behavior of the program and at least one Failing Test Case embodying the bug to be repaired. It consists of collecting data from multiple instrumented Test suite executions, transforming this data into a Satisfiability Modulo Theory (SMT) problem, and translating the SMT result -- if there exists one -- into a source code patch. Nopol repairs object oriented code and allows the patches to contain nullness checks as well as specific method calls.
-
Automatic Repair of Buggy If Conditions and Missing Preconditions with SMT
2014Co-Authors: Favio Demarco, Jifeng Xuan, Daniel Le Berre, Martin MonperrusAbstract:We present Nopol, an approach for automatically repairing buggy if conditions and missing preconditions. As input, it takes a program and a Test suite which contains passing Test Cases modeling the expected behavior of the program and at least one Failing Test Case embodying the bug to be repaired. It consists of collecting data from multiple instrumented Test suite executions, transforming this data into a Satisfiability Modulo Theory (SMT) problem, and translating the SMT result -- if there exists one -- into a source code patch. Nopol repairs object oriented code and allows the patches to contain nullness checks as well as specific method calls.
Thomas Durieux - One of the best experts on this subject based on the ideXlab platform.
-
From Runtime Failures to Patches: Study of Patch Generation in Production
2018Co-Authors: Thomas DurieuxAbstract:Patch creation is one of the most important actions in the life cycle of an application. Creating patches is a time-consuming task. Not only because it is difficult to create a sound and valid patch, but also because it requires the intervention of humans. Indeed, a user must report the bug, and a developer must reproduce it and fix it, which takes much time. To address this problem, techniques that automate this task have been created. However, those techniques still require a developer to reproduce the bug and encode it as a Failing Test Case. This requirement drastically reduces the applicability of the approaches since it still relies on humans. This thesis proposes new patch generation techniques that remove the human intervention for the patch generation. Our idea is to put as close as possible the patch generation in the production environment. We adopt this approach because the production environment contains all the data and human interactions that lead to the bug. In this thesis, we show how to exploit this data to detect bugs, generate and validate patches. We evaluate this approach on seven different benchmarks of real bugs collected from open-source projects. During the evaluation, we are particularly attentive to the number of generated patches, to their correctness, readability and to the time required for generating them. Our evaluation shows the applicability and feasibility of our approach to generate patches in the production environment without the intervention of a developer.
-
Production-Driven Patch Generation
2017Co-Authors: Thomas Durieux, Youssef Hamadi, Martin MonperrusAbstract:We present an original concept for patch generation: we propose to do it directly in production. Our idea is to generate patches on-the-fly based on automated analysis of the failure context. By doing this in production, the repair process has complete access to the system state at the point of failure. We propose to perform live regression Testing of the generated patches directly on the production traffic, by feeding a sandboxed version of the application with a copy of the production traffic, the “shadow traffic”. Our concept widens the applicability of program repair, because it removes the requirements of having a Failing Test Case.
-
ICSE-NIER - Production-driven patch generation
2017 IEEE ACM 39th International Conference on Software Engineering: New Ideas and Emerging Technologies Results Track (ICSE-NIER), 2017Co-Authors: Thomas Durieux, Youssef Hamadi, Martin MonperrusAbstract:We present an original concept for patch generation: we propose to do it directly in production. Our idea is to generate patches on-the-fly based on automated analysis of the failure context. By doing this in production, the repair process has complete access to the system state at the point of failure. We propose to perform live regression Testing of the generated patches directly on the production traffic, by feeding a sandboxed version of the application with a copy of the production traffic, the "shadow traffic". Our concept widens the applicability of program repair, because it removes the requirements of having a Failing Test Case.
-
Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset
Empirical Software Engineering, 2016Co-Authors: Matias Martinez, Thomas Durieux, Jifeng Xuan, Romain Sommerard, Martin MonperrusAbstract:Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J comes with a Test suite and at least one Failing Test Case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic Test-suite based repair on Defects4J. The result of our experiment shows that the considered state-of-the-art repair methods can generate patches for 47 out of 224 bugs. However, those patches are only Test-suite adequate, which means that they pass the Test suite and may potentially be incorrect beyond the Test-suite satisfaction correctness criterion. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly repaired with Test-suite based repair. This analysis shows that Test-suite based repair suffers from under-specified bugs, for which trivial or incorrect patches still pass the Test suite. With respect to practical applicability, it takes on average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All the repair systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.
-
Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs
IEEE Transactions on Software Engineering, 2016Co-Authors: Jifeng Xuan, M. Martinez, Favio Demarco, Maxime Clement, Sebastian R. Lamelas Marcote, Thomas Durieux, Daniel Le Berre, Martin MonperrusAbstract:We propose Nopol , an approach to automatic repair of buggy conditional statements (i.e., if-then-else statements). This approach takes a buggy program as well as a Test suite as input and generates a patch with a conditional expression as output. The Test suite is required to contain passing Test Cases to model the expected behavior of the program and at least one Failing Test Case that reveals the bug to be repaired. The process of Nopol consists of three major phases. First, Nopol employs angelic fix localization to identify expected values of a condition during the Test execution. Second, runtime trace collection is used to collect variables and their actual values, including primitive data types and objected-oriented features (e.g., nullness checks), to serve as building blocks for patch generation. Third, Nopol encodes these collected data into an instance of a Satisfiability Modulo Theory (SMT) problem; then a feasible solution to the SMT instance is translated back into a code patch. We evaluate Nopol on 22 real-world bugs (16 bugs with buggy if conditions and six bugs with missing preconditions) on two large open-source projects, namely Apache Commons Math and Apache Commons Lang. Empirical analysis on these bugs shows that our approach can effectively fix bugs with buggy if conditions and missing preconditions. We illustrate the capabilities and limitations of Nopol using Case studies of real bug fixes.
Durieux Thomas - One of the best experts on this subject based on the ideXlab platform.
-
Automatic Repair of Real Bugs in Java: A Large-Scale Experiment on the Defects4J Dataset
'Springer Science and Business Media LLC', 2018Co-Authors: Martinez Matias, Durieux Thomas, Sommerard Romain, Xuan Jifeng, Monperrus MartinAbstract:Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J comes with a Test suite and at least one Failing Test Case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic Test-suite based repair on Defects4J. The result of our experiment shows that the considered state-of-the-art repair methods can generate patches for 47 out of 224 bugs. However, those patches are only Test-suite adequate, which means that they pass the Test suite and may potentially be incorrect beyond the Test-suite satisfaction correctness criterion. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly repaired with Test-suite based repair. This analysis shows that Test-suite based repair suffers from under-specified bugs, for which trivial or incorrect patches still pass the Test suite. With respect to practical applicability, it takes on average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All the repair systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.Comment: Empirical Software Engineering, Springer, 2016. arXiv admin note: substantial text overlap with arXiv:1505.0700
-
Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs
'Institute of Electrical and Electronics Engineers (IEEE)', 2018Co-Authors: Xuan Jifeng, Martinez Matias, Durieux Thomas, Demarco Favio, Clément Maxime, Lamelas Sebastian, Daniel Le Berre, Monperrus MartinAbstract:We propose NOPOL, an approach to automatic repair of buggy conditional statements (i.e., if-then-else statements). This approach takes a buggy program as well as a Test suite as input and generates a patch with a conditional expression as output. The Test suite is required to contain passing Test Cases to model the expected behavior of the program and at least one Failing Test Case that reveals the bug to be repaired. The process of NOPOL consists of three major phases. First, NOPOL employs angelic fix localization to identify expected values of a condition during the Test execution. Second, runtime trace collection is used to collect variables and their actual values, including primitive data types and objected-oriented features (e.g., nullness checks), to serve as building blocks for patch generation. Third, NOPOL encodes these collected data into an instance of a Satisfiability Modulo Theory (SMT) problem, then a feasible solution to the SMT instance is translated back into a code patch. We evaluate NOPOL on 22 real-world bugs (16 bugs with buggy IF conditions and 6 bugs with missing preconditions) on two large open-source projects, namely Apache Commons Math and Apache Commons Lang. Empirical analysis on these bugs shows that our approach can effectively fix bugs with buggy IF conditions and missing preconditions. We illustrate the capabilities and limitations of NOPOL using Case studies of real bug fixes.Comment: IEEE Transactions on Software Engineering, 201
-
De l'erreur d'exécution aux correctifs: étude de la génération de correctifs en production
HAL CCSD, 2018Co-Authors: Durieux ThomasAbstract:Patch creation is one of the most important actions in the life cycle of an application. Creating patches is a time-consuming task. Not only because it is difficult to create a sound and valid patch, but also because it requires the intervention of humans. Indeed, a user must report the bug, and a developer must reproduce it and fix it, which takes much time. To address this problem, techniques that automate this task have been created. However, those techniques still require a developer to reproduce the bug and encode it as a Failing Test Case. This requirement drastically reduces the applicability of the approaches since it still relies on humans. This thesis proposes new patch generation techniques that remove the human intervention for the patch generation. Our idea is to put as close as possible the patch generation in the production environment. We adopt this approach because the production environment contains all the data and human interactions that lead to the bug. In this thesis, we show how to exploit this data to detect bugs, generate and validate patches. We evaluate this approach on seven different benchmarks of real bugs collected from open-source projects. During the evaluation, we are particularly attentive to the number of generated patches, to their correctness, readability and to the time required for generating them. Our evaluation shows the applicability and feasibility of our approach to generate patches in the production environment without the intervention of a developer.Dans le cadre de la gestion du cycle de vie d’une application, la création de correctifs de bugs est une des tâches les plus importantes. Or celle-ci prend aussi le plus de temps, non seulement parce qu'il est difficile de créer un bon correctif, mais également parce que cela nécessite des interventions humaines. Un utilisateur doit en effet signaler le bug et le développeur doit le reproduire et le corriger, processus long et fastidieux. Il existe des techniques qui automatisent cette tâche mais elles exigent toujours une intervention humaine à savoir qu'un développeur crée un Test reproduisant le bug, exigence qui réduit considérablement leur applicabilité. Dans le cadre de cette thèse, nous proposons une nouvelle approche de génération de correctifs qui s'affranchit de cette exigence. Elle repose sur l'idée de rapprocher le plus possible la génération de correctifs de l'environnement de production. En effet c’est celui-ci qui contient toutes les données et toutes les interactions humaines qui mènent aux bugs. Dans cette thèse, nous présentons comment exploiter ces données pour détecter les bugs, comment générer les correctifs et comment les valider, le tout sans l'intervention d'un développeur. Nous évaluons notre approche sur sept jeux différents de correctifs réels provenant de projets open-sources en veillant, entre autres, à être particulièrement attentifs au nombre de correctifs générés, à leur validité ainsi qu’au temps requis pour leur génération. Ces évaluations démontrent l'applicabilité et la faisabilité de notre approche dans la génération de correctifs en production sans l'intervention d'un développeur
Matias Martinez - One of the best experts on this subject based on the ideXlab platform.
-
Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset
Empirical Software Engineering, 2016Co-Authors: Matias Martinez, Thomas Durieux, Jifeng Xuan, Romain Sommerard, Martin MonperrusAbstract:Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J comes with a Test suite and at least one Failing Test Case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic Test-suite based repair on Defects4J. The result of our experiment shows that the considered state-of-the-art repair methods can generate patches for 47 out of 224 bugs. However, those patches are only Test-suite adequate, which means that they pass the Test suite and may potentially be incorrect beyond the Test-suite satisfaction correctness criterion. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly repaired with Test-suite based repair. This analysis shows that Test-suite based repair suffers from under-specified bugs, for which trivial or incorrect patches still pass the Test suite. With respect to practical applicability, it takes on average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All the repair systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.
