345 research outputs found
Memory and resource leak defects and their repairs in Java projects
Despite huge software engineering efforts and programming language support,
resource and memory leaks are still a troublesome issue, even in memory-managed
languages such as Java. Understanding the properties of leak-inducing defects,
how the leaks manifest, and how they are repaired is an essential prerequisite
for designing better approaches for avoidance, diagnosis, and repair of
leak-related bugs.
We conduct a detailed empirical study on 491 issues from 15 large open-source
Java projects. The study proposes taxonomies for the leak types, for the
defects causing them, and for the repair actions. We investigate, under several
aspects, the distributions within each taxonomy and the relationships between
them. We find that manual code inspection and manual runtime detection are
still the main methods for leak detection. We find that most of the errors
manifest on error-free execution paths, and developers repair the leak defects
in a shorter time than non-leak defects. We also identify 13 recurring code
transformations in the repair patches. Based on our findings, we draw a variety
of implications on how developers can avoid, detect, isolate and repair
leak-related bugs
Automated Fault Localization in Large Java Applications
Modern software systems evolve steadily. Software developers change the software codebase every day to add new features, to improve the performance, or to fix bugs.
Despite extensive testing and code inspection processes before releasing a new software version, the chance of introducing new bugs is still high. A code that
worked yesterday may not work today, or it can show a degraded performance causing software regression. The laws of software evolution state that the
complexity increases as software evolves. Such increasing complexity makes software maintenance harder and more costly. In a typical software organization, the cost of
debugging, testing, and verification can easily range from 50% to 75% of the total development costs.
Given that human resources are the main cost factor in the software maintenance and the software codebase evolves continuously, this dissertation tries to answer the
following question: How can we help developers to localize the software defects more effectively during software development? We answer this question in three aspects.
First, we propose an approach to localize failure-inducing changes for crashing bugs. Assume the source code of a buggy version, a failing test, the stack trace of the
crashing site, and a previous correct version of the application. We leverage program
analysis to contrast the behavior of the two software versions under the failing test.
The difference set is the code statements which contribute to the failure site with a high probability.
Second, we extend the version comparison technique to detect the leak-inducing defects caused by software changes. Assume two versions of a software codebase (one previous non-leaky and the current leaky version) and the existing test suite of the application. First, we compare the memory footprint of the code locations between two versions. Then, we use a confidence score to rank the suspicious code statements,
i.e., those statements which can be the potential root causes of memory leaks. The higher the score, the more likely the code statement is a potential leak.
Third, our observation on the related work about debugging and fault localization
reveals that there is no empirical study which characterizes the properties of the leak-
inducing defects and their repairs. Understanding the characteristics of the real defects
caused by resource and memory leaks can help both researchers and practitioners to improve the current techniques for leak detection and repair. To fill this gap, we conduct an empirical study on 491 reported resource and memory leak defects from 15 large Java applications. We use our findings to draw implications for leak avoidance,
detection, localization, and repair
Automatic Static Bug Detection for Machine Learning Libraries: Are We There Yet?
Automatic detection of software bugs is a critical task in software security.
Many static tools that can help detect bugs have been proposed. While these
static bug detectors are mainly evaluated on general software projects call
into question their practical effectiveness and usefulness for machine learning
libraries. In this paper, we address this question by analyzing five popular
and widely used static bug detectors, i.e., Flawfinder, RATS, Cppcheck,
Facebook Infer, and Clang static analyzer on a curated dataset of software bugs
gathered from four popular machine learning libraries including Mlpack, MXNet,
PyTorch, and TensorFlow with a total of 410 known bugs. Our research provides a
categorization of these tools' capabilities to better understand the strengths
and weaknesses of the tools for detecting software bugs in machine learning
libraries. Overall, our study shows that static bug detectors find a negligible
amount of all bugs accounting for 6/410 bugs (0.01%), Flawfinder and RATS are
the most effective static checker for finding software bugs in machine learning
libraries. Based on our observations, we further identify and discuss
opportunities to make the tools more effective and practical
PreciseBugCollector: Extensible, Executable and Precise Bug-fix Collection
Bug datasets are vital for enabling deep learning techniques to address
software maintenance tasks related to bugs. However, existing bug datasets
suffer from precise and scale limitations: they are either small-scale but
precise with manual validation or large-scale but imprecise with simple commit
message processing. In this paper, we introduce PreciseBugCollector, a precise,
multi-language bug collection approach that overcomes these two limitations.
PreciseBugCollector is based on two novel components: a) A bug tracker to map
the codebase repositories with external bug repositories to trace bug type
information, and b) A bug injector to generate project-specific bugs by
injecting noise into the correct codebases and then executing them against
their test suites to obtain test failure messages.
We implement PreciseBugCollector against three sources: 1) A bug tracker that
links to the national vulnerability data set (NVD) to collect general-wise
vulnerabilities, 2) A bug tracker that links to OSS-Fuzz to collect
general-wise bugs, and 3) A bug injector based on 16 injection rules to
generate project-wise bugs. To date, PreciseBugCollector comprises 1057818 bugs
extracted from 2968 open-source projects. Of these, 12602 bugs are sourced from
bug repositories (NVD and OSS-Fuzz), while the remaining 1045216
project-specific bugs are generated by the bug injector. Considering the
challenge objectives, we argue that a bug injection approach is highly valuable
for the industrial setting, since project-specific bugs align with domain
knowledge, share the same codebase, and adhere to the coding style employed in
industrial projects.Comment: Accepted at the industry challenge track of ASE 202
1997 Research Reports: NASA/ASEE Summer Faculty Fellowship Program
This document is a collection of technical reports on research conducted by the participants in the 1997 NASA/ASEE Summer Faculty Fellowship Program at the Kennedy Space Center (KSC). This was the 13th year that a NASA/ASEE program has been conducted at KSC. The 1997 program was administered by the University of Central Florida in cooperation with KSC. The program was operated under the auspices of the American Society for Engineering Education (ASEE) with sponsorship and funding from the Education Division, NASA Headquarters, Washington, D.C., and KSC. The KSC Program was one of nine such Aeronautics and Space Research Programs funded by NASA in 1997. The NASA/ASEE Program is intended to be a two-year program to allow in-depth research by the university faculty member. The editors of this document were responsible for selecting appropriately qualified faculty to address some of the many problems of current interest to NASA/KSC
- …