The Google FindBugs fixit

Ayewah, Nathaniel; Pugh, William

doi:10.1145/1831708.1831738

Cited by 108 publications

(70 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A threat to the internal validity of our dataset construction process could be the false alarms of the FindBugs tool [1]. Specifically, reported security bugs may not be applicable to A disadvantage of our dataset is that as projects evolve the dataset gets older.…”

Section: Limitationsmentioning

confidence: 99%

See 1 more Smart Citation

The bug catalog of the maven ecosystem

Mitropoulos

Karakoidas

Λουρίδας

et al. 2014

Proceedings of the 11th Working Conference on Mining Software Repositories

View full text Add to dashboard Cite

Examining software ecosystems can provide the research community with data regarding artifacts, processes, and communities. We present a dataset obtained from the Maven central repository ecosystem (approximately 265gb of data) by statically analyzing the repository to detect potential software bugs. For our analysis we used FindBugs, a tool that examines Java bytecode to detect numerous types of bugs. The dataset contains the metrics results that FindBugs reports for every project version (a jar) included in the ecosystem. For every version we also stored specific metadata such as the jar's size, its dependencies and others. Our dataset can be used to produce interesting research results, as we show in specific examples.

show abstract

Section: Limitationsmentioning

confidence: 99%

“…To statically analyze the Maven repository we used FindBugs, 7 a static analysis tool that examines bytecode to detect software bugs and has already been used in research [1,7]. Specifically, we ran FindBugs on all the project versions of all the projects that exist in the repository to identify all bugs contained in it.…”

mentioning

confidence: 99%

The bug catalog of the maven ecosystem

Mitropoulos

Karakoidas

Λουρίδας

et al. 2014

Proceedings of the 11th Working Conference on Mining Software Repositories

View full text Add to dashboard Cite

show abstract

“…The requirements for having a valid and useful residual investigation then become: 1 The computing literature is remarkably inconsistent in the use of the terms "error", "fault", "failure", etc. In plain English "error" and "fault" are dictionary synonyms.…”

Section: Preliminary Discussionmentioning

confidence: 99%

“…False error reports are the bane of automatic bug detection-this experience is perhaps the most often-reported in the program analysis research literature [1,21,22,27,28]. Programmers are quickly frustrated and much less likely to trust an automatic tool if they observe that reported errors are often not real errors, or are largely irrelevant in the given context.…”

Section: Introductionmentioning

confidence: 99%

“…Consider as an example the "equal objects must have equal hashcodes" analysis (codenamed HE) in the FindBugs static error detector for Java [1,14,16]. The HE analysis emits a warning whenever a class overrides the method equals(Object) (originally defined in the Object class, the ancestor of all Java classes) without overriding the hashCode() method (or vice versa).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Residual investigation: predictive and precise bug detection

Reichenbach

Csallner

et al. 2012

Proceedings of the 2012 International Symposium on Software Testing and Analysis

View full text Add to dashboard Cite

We introduce the concept of "residual investigation" for program analysis. A residual investigation is a dynamic check installed as a result of running a static analysis that reports a possible program error. The purpose is to observe conditions that indicate whether the statically predicted program fault is likely to be realizable and relevant. The key feature of a residual investigation is that it has to be much more precise (i.e., with fewer false warnings) than the static analysis alone, yet significantly more general (i.e., reporting more errors) than the dynamic tests in the program's test suite pertinent to the statically reported error. That is, good residual investigations encode dynamic conditions that, when taken in conjunction with the static error report, increase confidence in the existence of an error, as well as its severity, without needing to directly observe a fault resulting from the error.We enhance the static analyzer FindBugs with several residual investigations, appropriately tuned to the static error patterns in FindBugs, and apply it to 7 large open-source systems and their native test suites. The result is an analysis with a low occurrence of false warnings ("false positives") while reporting several actual errors that would not have been detected by mere execution of a program's test suite.

show abstract

Data mining for defects in multicore applications: an entropy‐based call‐graph technique

Eichinger¹,

Pankratius

Böhm

2012

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARYMulticore computers are ubiquitous. Expert developers as well as developers with little experience in parallelism are now asked to create multithreaded software in order to exploit parallelism in mainstream shared-memory hardware. However, finding and fixing parallel programming errors is a complex and arduous task. Programmers thus rely on tools such as race detectors that typically focus on reporting errors due to incorrect usage of synchronization constructs or due to missing synchronization. This arsenal of debugging techniques, however, is incomplete. This article presents a new perspective and addresses a largely unexplored direction of defect localization where a wrong usage of non-parallel programming constructs might cause wrong parallel application behavior. In particular, we make a contribution by showing how to use data-mining techniques to locate defects in multithreaded shared-memory programs. Our technique analyzes execution anomalies in a condensed representation of the dynamic call graphs of a multithreaded object-oriented application and identifies methods that contain a defect. Compared to race detectors that concentrate on finding incorrect synchronization, our method is able to reveal a wider range of defects that affect the control flow of a parallel program. Results from controlled experiments show that our data-mining approach not only finds race conditions in different types of multicore applications, but also other errors that cause incorrect parallel program behavior. Data-mining techniques offer a fruitful new ground for parallel program debugging, and we also discuss long-term directions for this interesting field.

show abstract

The Google FindBugs fixit

Cited by 108 publications

References 16 publications

The bug catalog of the maven ecosystem

The bug catalog of the maven ecosystem

Residual investigation: predictive and precise bug detection

Data mining for defects in multicore applications: an entropy‐based call‐graph technique

Contact Info

Product

Resources

About