Results 1 - 10
of
240
Automatically Finding Patches Using Genetic Programming ∗
"... Automatic program repair has been a longstanding goal in software engineering, yet debugging remains a largely manual process. We introduce a fully automated method for locating and repairing bugs in software. The approach works on off-the-shelf legacy applications and does not require formal specif ..."
Abstract
-
Cited by 146 (24 self)
- Add to MetaCart
Automatic program repair has been a longstanding goal in software engineering, yet debugging remains a largely manual process. We introduce a fully automated method for locating and repairing bugs in software. The approach works on off-the-shelf legacy applications and does not require formal specifications, program annotations or special coding practices. Once a program fault is discovered, an extended form of genetic programming is used to evolve program variants until one is found that both retains required functionality and also avoids the defect in question. Standard test cases are used to exercise the fault and to encode program requirements. After a successful repair has been discovered, it is minimized using structural differencing algorithms and delta debugging. We describe the proposed method and report experimental results demonstrating that it can successfully repair ten different C programs totaling 63,000 lines in under 200 seconds, on average. 1
An approach to detecting duplicate bug reports using natural language and execution information
- In ICSE ’08: Proceedings of the 30th International Conference on Software Engineering
, 2008
"... An open source project typically maintains an open bug repository so that bug reports from all over the world can be gathered. When a new bug report is submitted to the repository, a person, called a triager, examines whether it is a duplicate of an existing bug report. If it is, the triager marks i ..."
Abstract
-
Cited by 122 (12 self)
- Add to MetaCart
(Show Context)
An open source project typically maintains an open bug repository so that bug reports from all over the world can be gathered. When a new bug report is submitted to the repository, a person, called a triager, examines whether it is a duplicate of an existing bug report. If it is, the triager marks it as DUPLICATE and the bug report is removed from consideration for further work. In the literature, there are approaches exploiting only natural language information to detect duplicate bug reports. In this paper we present a new approach that further involves execution information. In our approach, when a new bug report arrives, its natural language information and execution information are compared with those of the existing bug reports. Then, a small number of existing bug reports are suggested to the triager as the most similar bug reports to the new bug report. Finally, the triager examines the suggested bug reports to determine whether the new bug report duplicates an existing bug report. We calibrated our approach on a subset of the Eclipse bug repository and evaluated our approach on a subset of the Firefox bug repository. The experimental results show that our approach can detect 67%-93 % of duplicate bug reports in the Firefox bug repository, compared to 43%-72% using natural language information alone.
What makes a good bug report?
- In International Symposium on Foundations of Software Engineering,
, 2008
"... ..."
(Show Context)
Global Software Engineering: The Future of Socio-technical Coordination
- In International Conference on Software Engineering: Future of Software Engineering (FOSE'07
, 2007
"... source software engineering, as well as coordination in collaborative work more generally. Prior to joining the faculty of Carnegie Mellon University, he initiated the Bell Labs Collaboratory project, leading a research team which designed, implemented, and deployed solutions for global development, ..."
Abstract
-
Cited by 107 (0 self)
- Add to MetaCart
(Show Context)
source software engineering, as well as coordination in collaborative work more generally. Prior to joining the faculty of Carnegie Mellon University, he initiated the Bell Labs Collaboratory project, leading a research team which designed, implemented, and deployed solutions for global development, including tools, practices, and organizational models. He has also published papers describing how open source software development actually works, its limitations, and the extent to which open source practices can be applied in industrial settings.
A survey and taxonomy of approaches for mining software repositories in the context of software evolution
, 2007
"... ..."
How long will it take to fix this bug
- In Workshop on Mining Software Repositories
, 2007
"... Predicting the time and effort for a software problem has long been a difficult task. We present an approach that au-tomatically predicts the fixing effort, i.e., the person-hours spent on fixing an issue. Our technique leverages existing issue tracking systems: given a new issue report, we use the ..."
Abstract
-
Cited by 82 (8 self)
- Add to MetaCart
(Show Context)
Predicting the time and effort for a software problem has long been a difficult task. We present an approach that au-tomatically predicts the fixing effort, i.e., the person-hours spent on fixing an issue. Our technique leverages existing issue tracking systems: given a new issue report, we use the Lucene framework to search for similar, earlier reports and use their average time as a prediction. Our approach thus allows for early effort estimation, helping in assign-ing issues and scheduling stable releases. We evaluated our approach using effort data from the JBoss project. Given a sufficient number of issues reports, our automatic predic-tions are close to the actual effort; for issues that are bugs, we are off by only one hour, beating naı̈ve predictions by a factor of four. 1.
A Systematic Study of Automated Program Repair: Fixing 55 out of 105 Bugs for $8 Each
"... Abstract—There are more bugs in real-world programs than human programmers can realistically address. This paper evaluates two research questions: “What fraction of bugs can be repaired automatically? ” and “How much does it cost to repair a bug automatically? ” In previous work, we presented GenPro ..."
Abstract
-
Cited by 71 (17 self)
- Add to MetaCart
Abstract—There are more bugs in real-world programs than human programmers can realistically address. This paper evaluates two research questions: “What fraction of bugs can be repaired automatically? ” and “How much does it cost to repair a bug automatically? ” In previous work, we presented GenProg, which uses genetic programming to repair defects in off-the-shelf C programs. To answer these questions, we: (1) propose novel algorithmic improvements to GenProg that allow it to scale to large programs and find repairs 68 % more often, (2) exploit GenProg’s inherent parallelism using cloud computing resources to provide grounded, humancompetitive cost measurements, and (3) generate a large, indicative benchmark set to use for systematic evaluations. We evaluate GenProg on 105 defects from 8 open-source programs totaling 5.1 million lines of code and involving 10,193 test cases. GenProg automatically repairs 55 of those 105 defects. To our knowledge, this evaluation is the largest available of its kind, and is often two orders of magnitude larger than previous work in terms of code or test suite size or defect count. Public cloud computing prices allow our 105 runs to be reproduced for $403; a successful repair completes in 96 minutes and costs $7.32, on average. Keywords-genetic programming; automated program repair; cloud computing I.
Improving bug triage with bug tossing graphs
- In ESEC/FSE ’09: Proceedings of the European Software Engineering Conference and Symposium on the Foundations of Software Engineering
, 2009
"... A bug report is typically assigned to a single developer who is then responsible for fixing the bug. In Mozilla and Eclipse, between 37%-44 % of bug reports are “tossed ” (reassigned) to other devel-opers, for example because the bug has been assigned by accident or another developer with additional ..."
Abstract
-
Cited by 70 (7 self)
- Add to MetaCart
(Show Context)
A bug report is typically assigned to a single developer who is then responsible for fixing the bug. In Mozilla and Eclipse, between 37%-44 % of bug reports are “tossed ” (reassigned) to other devel-opers, for example because the bug has been assigned by accident or another developer with additional expertise is needed. In any case, tossing increases the time-to-correction for a bug. In this paper, we introduce a graph model based on Markov chains, which captures bug tossing history. This model has sev-eral desirable qualities. First, it reveals developer networks which can be used to discover team structures and to find suitable experts for a new task. Second, it helps to better assign developers to bug reports. In our experiments with 445,000 bug reports, our model reduced tossing events, by up to 72%. In addition, the model in-creased the prediction accuracy by up to 23 percentage points com-pared to traditional bug triaging approaches. Categories and Subject Descriptors D2.7 [Software Engineering]: Distribution, Maintenance, and En-
Classifying Software Changes: Clean or Buggy?
, 2008
"... This paper introduces a new technique for predicting latent software bugs, called change classification. Change classification uses a machine learning classifier to determine whether a new software change is more similar to prior buggy changes or clean changes. In this manner, change classification ..."
Abstract
-
Cited by 65 (11 self)
- Add to MetaCart
This paper introduces a new technique for predicting latent software bugs, called change classification. Change classification uses a machine learning classifier to determine whether a new software change is more similar to prior buggy changes or clean changes. In this manner, change classification predicts the existence of bugs in software changes. The classifier is trained using features (in the machine learning sense) extracted from the revision history of a software project stored in its software configuration management repository. The trained classifier can classify changes as buggy or clean, with a 78 percent accuracy and a 60 percent buggy change recall on average. Change classification has several desirable qualities: 1) The prediction granularity is small (a change to a single file), 2) predictions do not require semantic information about the source code, 3) the technique works for a broad array of project types and programming languages, and 4) predictions can be made immediately upon the completion of a change. Contributions of this paper include a description of the change classification approach, techniques for extracting features from the source code and change histories, a characterization of the performance of change classification across 12 open source projects, and an evaluation of the predictive power of different groups of features.
Codebook: Discovering and Exploiting Relationships in Software Repositories
"... Large-scale software engineering requires communication and collaboration to successfully build and ship products. We conducted a survey with Microsoft engineers on inter-team coordination and found that the most impactful problems concerned finding and keeping track of other engineers. Since engine ..."
Abstract
-
Cited by 64 (9 self)
- Add to MetaCart
(Show Context)
Large-scale software engineering requires communication and collaboration to successfully build and ship products. We conducted a survey with Microsoft engineers on inter-team coordination and found that the most impactful problems concerned finding and keeping track of other engineers. Since engineers are connected by their shared work, a tool that discovers connections in their work-related repositories can help. Here we describe the Codebook framework for mining software repositories. It is flexible enough to address all of the problems identified by our survey with a single data structure (graph of people and artifacts) and a single algorithm (regular language reachability). Codebook handles a larger variety of problems than prior work, analyzes more kinds of work artifacts, and can be customized by and for end-users. To evaluate our framework’s flexibility, we built two applications, Hoozizat and Deep Intellisense. We evaluated these applications with engineers to show effectiveness in addressing multiple inter-team coordination problems. Categories and Subject Descriptors:
