13,112 research outputs found
Detect Related Bugs from Source Code Using Bug Information
Open source projects often maintain open bug repositories during development
and maintenance, and the reporters often point out straightly or implicitly the
reasons why bugs occur when they submit them. The comments about a bug are very
valuable for developers to locate and fix the bug. Meanwhile, it is very common
in large software for programmers to override or overload some methods
according to the same logic. If one method causes a bug, it is obvious that
other overridden or overloaded methods maybe cause related or similar bugs. In
this paper, we propose and implement a tool Rebug- Detector, which detects
related bugs using bug information and code features. Firstly, it extracts bug
features from bug information in bug repositories; secondly, it locates bug
methods from source code, and then extracts code features of bug methods;
thirdly, it calculates similarities between each overridden or overloaded
method and bug methods; lastly, it determines which method maybe causes
potential related or similar bugs. We evaluate Rebug-Detector on an open source
project: Apache Lucene-Java. Our tool totally detects 61 related bugs,
including 21 real bugs and 10 suspected bugs, and it costs us about 15.5
minutes. The results show that bug features and code features extracted by our
tool are useful to find real bugs in existing projects.Comment: 10 pages, 5 figures, 4 tables conference; 2010 IEEE 34th Annual
Computer Software and Applications Conferenc
Are developers fixing their own bugs?: Tracing bug-fixing and bug-seeding committers
This is the post-print version of the Article. The official published version can be accessed from the link below - Copyright @ 2011 IGI GlobalThe process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.This work has been partially funded by the European Commission, under the ALERT project (ICT-258098)
Towards Automated Performance Bug Identification in Python
Context: Software performance is a critical non-functional requirement,
appearing in many fields such as mission critical applications, financial, and
real time systems. In this work we focused on early detection of performance
bugs; our software under study was a real time system used in the
advertisement/marketing domain.
Goal: Find a simple and easy to implement solution, predicting performance
bugs.
Method: We built several models using four machine learning methods, commonly
used for defect prediction: C4.5 Decision Trees, Na\"{\i}ve Bayes, Bayesian
Networks, and Logistic Regression.
Results: Our empirical results show that a C4.5 model, using lines of code
changed, file's age and size as explanatory variables, can be used to predict
performance bugs (recall=0.73, accuracy=0.85, and precision=0.96). We show that
reducing the number of changes delivered on a commit, can decrease the chance
of performance bug injection.
Conclusions: We believe that our approach can help practitioners to eliminate
performance bugs early in the development cycle. Our results are also of
interest to theoreticians, establishing a link between functional bugs and
(non-functional) performance bugs, and explicitly showing that attributes used
for prediction of functional bugs can be used for prediction of performance
bugs
How Effective are Smart Contract Analysis Tools? Evaluating Smart Contract Static Analysis Tools Using Bug Injection
Security attacks targeting smart contracts have been on the rise, which have
led to financial loss and erosion of trust. Therefore, it is important to
enable developers to discover security vulnerabilities in smart contracts
before deployment. A number of static analysis tools have been developed for
finding security bugs in smart contracts. However, despite the numerous
bug-finding tools, there is no systematic approach to evaluate the proposed
tools and gauge their effectiveness. This paper proposes SolidiFI, an automated
and systematic approach for evaluating smart contract static analysis tools.
SolidiFI is based on injecting bugs (i.e., code defects) into all potential
locations in a smart contract to introduce targeted security vulnerabilities.
SolidiFI then checks the generated buggy contract using the static analysis
tools, and identifies the bugs that the tools are unable to detect
(false-negatives) along with identifying the bugs reported as false-positives.
SolidiFI is used to evaluate six widely-used static analysis tools, namely,
Oyente, Securify, Mythril, SmartCheck, Manticore and Slither, using a set of 50
contracts injected by 9369 distinct bugs. It finds several instances of bugs
that are not detected by the evaluated tools despite their claims of being able
to detect such bugs, and all the tools report many false positivesComment: ISSTA 202
Automatic Repair of Infinite Loops
Research on automatic software repair is concerned with the development of
systems that automatically detect and repair bugs. One well-known class of bugs
is the infinite loop. Every computer programmer or user has, at least once,
experienced this type of bug. We state the problem of repairing infinite loops
in the context of test-suite based software repair: given a test suite with at
least one failing test, generate a patch that makes all test cases pass.
Consequently, repairing infinites loop means having at least one test case that
hangs by triggering the infinite loop. Our system to automatically repair
infinite loops is called . We develop a technique to manipulate
loops so that one can dynamically analyze the number of iterations of loops;
decide to interrupt the loop execution; and dynamically examine the state of
the loop on a per-iteration basis. Then, in order to synthesize a new loop
condition, we encode this set of program states as a code synthesis problem
using a technique based on Satisfiability Modulo Theory (SMT). We evaluate our
technique on seven seeded-bugs and on seven real-bugs. is able to
repair all of them, within seconds up to one hour on a standard laptop
configuration
- âŚ