Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
11
datasets available to search
ShareScore release 0.9.0
Dataset results
11 results for “Software Bugs”
Dataset of the paper "An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical Systems"
<p><br> #Dataset Package for the paper "An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical Systems"</p> <p><br> Description of the content:</p> <p><br> 1) "1_RQ-CPS-bugs-Taxonomy" folder contains all the main experimental data concerning the issues sampled and analyzed from all the Projects considered in the study,<br> including row-data on the taxonomy validtion steps.<br> <br> - Under "the sub-folder "1_Taxonomy-Raw-data" are reported the row-data concerning the taxonomy validtion steps </p> <p><br> 2) "2_Scripts" contains all scripts used to generate the issue data and sampled issue raw-data in the previous folders: </p> <p><br> - "setup.md" file in the folder describes how to set=up and run the script used for collecting and sampling the issues for the validation steps:<br> <br> - runJSONtoCSV.sh<br> - JSONtoCSV.py<br> - generateListOfAllSamples.py<br> - generateAllSamples.r<br> <br> Under "the sub-folder "1_Scripts/1_Data_Collection":<br> <br> <br> 3) "3_Final Taxonomy" folder contains the final Table representation (also reported in the previous folder) and main figures of the CPSs Bugs Taxonomy.</p>
Are Neural Bug Detectors Comparable to Software Developers on Variable Misuse Bugs?
<p>Artifact for "Are Neural Bug Detectors Comparable to Software Developers on Variable Misuse Bugs?"</p> <p><strong>Abstract:</strong> </p> <p>Debugging, that is, identifying and fixing bugs in software, is a central part of software development. Developers are therefore often confronted with the task of deciding whether a given code snippet contains a bug, and if yes, where. Recently, data-driven methods have been employed to learn this task of bug detection, resulting (amongst others) in so called neural bug detectors. Neural bug detectors are trained on millions of buggy and correct code snippets.</p> <p>Given the “neural learning” procedure, it seems likely that neu- ral bug detectors – on the specific task of finding bugs – have a performance similar to human software developers. For this work, we set out to substantiate or refute such a hypothesis. We report on the results of an empirical study with over 100 software developers, targeting the comparison of humans and neural bug detectors. As detection task, we chose a specific form of bugs (variable misuse bugs) for which neural bug detectors have recently made significant progress. Our study shows that despite the fact that neural bug detectors see millions of such misuse bugs during training, software developers – when conducting bug detection as a majority decision – are slightly better than neural bug detectors on this class of bugs. Altogether, we find a large overlap in the performance, both for classifying code as buggy and for localizing the buggy line in the code. In comparison to developers, one of the two evaluated neural bug detectors, however, raises a higher number of false alarms in our study.</p> <p><strong>Content:</strong> The artifact includes the following components:</p> <ul> <li> <p><strong>Web UI:</strong> The developer survey was performed online in the browser of the participants. For this, we created a custom web interface tailored for our study task. We included both the implementation of the frontend (website) and backend implementation (buisness logic and database) in this artifact. Therefore, it is not only possible to replicate our survey with same interface and a new group of participants but it is also possible to extend the interface for future studies. </p> </li> <li> <p><strong>Neural bug detectors: </strong>We evaluate the performance of the developers against two neural bug detectors. In this artifact, we include the bug detectors (implementation + trained models) and the evaluation script used for producing our results. Besides the replication of our bug detector evaluation, the detectors can also be used in future projects for detecting variable misuse bugs in Java methods.</p> </li> <li> <p><strong>Analysis scripts</strong>: After collecting the raw results from the developers and neural bug detectors, we performed several analysis to gain insights how developers and bug detectors compare on the variable misuse task. We include all analysis steps in form of Jupyter notebooks in the artifact. With this, it is possible to reproduce all the figures of our paper. </p> </li> </ul> <p>In addition, we also provide further artifacts that were successfully evaluated at ASE 2022:</p> <p><strong>ASE 2022 Artifact: </strong><a href="https://doi.org/10.5281/zenodo.6958242">10.5281/zenodo.6958242</a></p> <p><strong>Virtual machine: </strong><a href="https://doi.org/10.5281/zenodo.6957849">10.5281/zenodo.6957849</a></p>
Bugsplainer: Explaining Software Bugs Leveraging Code Structures in Neural Machine Translation
<p>Software bugs claim approximately 50% of development time and cost the global economy billions of dollars. Once a bug is reported, the assigned developer attempts to identify and understand the source code responsible for the bug and then corrects the code. Over the last five decades, there has been significant research on automatically finding or correcting software bugs. However, there has been little research on automatically explaining the bugs to the developers, which is essential but a highly challenging task. In this paper, we propose Bugsplainer, a transformer-based generative model, that generates natural language explanations for software bugs by learning from a large corpus of bug-fix commits. Bugsplainer can leverage structural information and buggy patterns from the source code to generate an explanation for a bug. Our evaluation using three performance metrics shows that Bugsplainer can generate understandable and good explanations according to Google's standard, and can outperform multiple baselines from the literature. We also conduct a developer study involving 20 participants where the explanations from Bugsplainer were found to be more accurate, more precise, more concise and more useful than the baselines.</p>
Aging-related bugs and software complexity metrics
<p>This dataset contains information on aging-related bugs found in two open-source projects (the Linux kernel and the MySQL DBMS). This dataset has been used to investigate defect prediction approaches for aging-related bugs, by using software complexity metrics and machine learning techniques. New software complexity metrics were proposed in this study to support defect prediction ("aging-related" metrics).</p> <p>The dataset contains an ARFF file for each subsystem of the open-source projects. Each row of the ARFF file contains:</p> <p>- The name of a file in the project;</p> <p>- "Program size" metrics for the file (columns from 2 to 50);</p> <p>- "McCabe's cyclomatic complexity" metrics for the file (columns from 51 to 68);</p> <p>- "Halstead" metrics for the file (columns from 69 to 77);</p> <p>- "Aging-related" metrics for the file (columns from 78 to 83);</p> <p>- The number of aging-related bugs found in the file.<br> </p>
Artifact for "Inside Bug Report Templates: An Empirical Study on Bug Report Templates in Open-Source Software"
<p>This is the artifact for the paper "Inside Bug Report Templates: An Empirical Study on Bug Report Templates in Open-Source Software".</p> <p><strong>What the artifact does:</strong><br>1) a questionnaire that we used for our online survey (PDF);<br>2) the valid responses of our online survey (CSV).</p> <p>3) the code of preprocessing (.py).</p> <p>4) the dataset of preprocessing and labeling (CSV).</p>
Artifact for "MAAT: A Novel Ensemble Approach to Addressing Fairness and Performance Bugs for Machine Learning Software"
<p>This artifact is for the paper entitled “MAAT: A Novel Ensemble Approach to Addressing Fairness and Performance Bugs for Machine Learning Software”, which is accepted by ESEC/FSE 2022. MAAT is a novel ensemble approach to improving the fairness-performance trade-off for ML software. It outperforms state-of-the-art bias mitigation methods. The artifact has also been placed on GitHub (https://github.com/chenzhenpeng18/FSE22-MAAT) under the Apache License, publicly accessible to other researchers. In this artifact, we provide the source code of MAAT and other existing bias mitigation methods that we use in our study, as well as the intermediate results, the installation instructions, and a replication guideline (included in the README). The replication guideline provides detailed steps to replicate all the results for all the research questions.</p>
Revisiting reopened bugs in open source software systems
<p>Reopened bugs can degrade the overall quality of a software system since they require unnecessary rework by developers. Moreover, reopened bugs also lead to a loss of trust in the end-users regarding the quality of the software. Thus, predicting bugs that might be reopened could be extremely helpful for software developers to avoid rework. Prior studies on reopened bug prediction focus only on three open source projects (i.e., Apache, Eclipse, and OpenOffice) to generate insights. We observe that one out of the three projects (i.e., Apache) has a data leak issue -- the bug status of \textit{reopened} was included as training data to predict reopened bugs. In addition, prior studies used an outdated prediction model pipeline (i.e., with old techniques for constructing a prediction model) to predict reopened bugs. Therefore, we revisit the reopened bugs study on a large scale dataset consisting of 47 projects tracked by JIRA using the modern techniques such as SMOTE, permutation importance together with 7 different machine learning models. We study the reopened bugs using a mixed methods approach (i.e., both quantitative and qualitative study). We find that: 1) After using an updated reopened bug prediction model pipeline, only 34\% projects give an acceptable performance with AUC $\geqslant$ 0.7. 2) There are four major reasons for a bug getting reopened, that is, technical (i.e., patch/integration issues), documentation, human (i.e., due to incorrect bug assessment), and reasons not shown in the bug reports. 3) In projects with an acceptable AUC, 94\% of the reopened bugs are due to patch issues (i.e., the usage of an incorrect patch) identified before bug reopening. Our study revisits reopened bugs and provides new insights into developer's bug reopening activities.<br> </p>
Predicting Bug-Inducing Commits Using Software Quality Metrics
Open the record for dataset details and reuse information.
Bug Report Analytics for Software Reliability Assessment using Hybrid Swarm-Evolutionary Algorithm
<p><span>There are in total 6 files.</span></p> <p><span><span>1.<span> </span></span></span><span>Out of these files three documents are related to datasets. Two are related to unrefined Eclipse and JDT files and third is refined data of Eclipse and JDT Project Failure Datasets which has been used for experimentation purpose.</span></p> <p><span><span>2.<span> </span></span></span><span>This package also includes code for all the models version wise for all versions of Eclipse and JDT projects.</span></p> <p><span><span>3.<span> </span></span></span><span>Sample Code has also been given for version 4.3 and 4.10. </span></p> <p><span>Steps to run </span></p> <p><span><span>a)<span> </span></span></span><span>In this code, Main ABCDE file needs to be run and different datasets could be executed on this file. This is for one type of datasets that is time domain dataset only. </span></p> <p><span><span>b)<span> </span></span></span><span>If anyone is interested in getting separate results for cumulative sum and failure intensity, separate file has been given. </span></p> <p><span><span>c)<span> </span></span></span><span>Code for ABCDE algorithm that is Swarm Evolutionary algorithm used in the paper has also been given in these files.</span></p>
Dataset of bugs in automated driving softwares
Open the record for dataset details and reuse information.
[Dataset] Minecraft: Automated Mining of Software Bug Fixes with Precise Code Context
<p>Repository mining of bug fixes from version control systems like GitHub is a challenging problem as far as the precision of the bug context is concerned before and after the fix. Coupled with this, identification of the type of the bug fix goes a long way towards creating high quality datasets that can be used for several downstream tasks. However, existing bug fix datasets suffer from the following limitations that dilute the data quality. Firstly, they do not focus on multilingual projects in their entirety given that most open-source projects are now multilingual. Secondly, the granularity of the bug fixes are considered only at the function/method level without specifying line/statement level information. Thirdly, bug fixes lying within the scope of a source file but outside any of its constituent functions have not been examined. In this paper, we propose a solution to overcome the aforementioned limitations by introducing a novel and extensive dataset named Minecraft. With a size of 28.8GB (considering 416 GitHub projects encompassing programming languages such as C, C++, Java, and Python, 2.2M commits, 3.29M bug-fix pairs), Minecraft surpasses the existing datasets by 4-fold enlargement in terms of data availability. We believe Minecraft would serve as a valuable resource for various stakeholders in the software development and research communities, empowering them to improve software quality, develop innovative bug detection and auto-fix techniques, and<br> advance the field of software engineering.<br> </p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.