Bug Fixing Research Articles

Exploring the Use of Chatrooms by Developers: An Empirical Study on Slack and Gitter

Communication is critical for the software development teams to maintain project awareness, facilitate project co-ordination and avoid misunderstandings. The features offered in the chatrooms, such as private messaging, group conversations, and code sharing help accommodate the communication needs of the software development teams. Therefore, chatrooms have been increasingly adopted among the developers. Since the last study on Slack performed by (Lin <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">et al.</i> 2016), the audience of Slack has more than doubled possibly leading to an evolution of the ways Slack is used; while another rich community formed around Gitter and remains unstudied. In this paper, we perform an investigative study using qualitative and quantitative techniques to gain insights on the use of popular modern chatrooms, specifically Slack and Gitter. Based on the survey responses from 163 developers, the interviews with 21 developers, and the chatroom data collected from 11 Slack and 770 Gitter rooms, we are able to uncover the reasons behind the use of Slack and Gitter, the perceived impact on the associated projects, and the quality determinants of the two chatrooms. We find that the developers seek knowledge from the chatrooms to obtain timely feedback from experts, and in return share their expertise to build the project community and their reputations. Furthermore, it is perceived by the Gitter developers that the chatrooms have an impact on prioritizing the new features and the bug fixes. In Slack, the most reported impact concerns an increased project awareness, in terms of a better tracking of the work progress. As reported on the developers’ survey, both Slack and Gitter chat services have a visible impact on mentoring developers, and sharing the best practices. In terms of quality determinants, a non-ephemeral history and a better history management (e.g., advanced search) could be keys for both chat services to reach their full potential.

Like, dislike, or just do it? How developers approach software development tasks

Software developers work on various tasks and activities that contribute towards creating and maintaining software applications, frameworks, or other software components. These include technical (e.g., writing code and fixing bugs) and non-technical activities (e.g., communicating within or outside teams to understand, clarify, and resolve issues) as part of their day-to-day responsibilities. Interestingly, there is an aspect of desirability associated with these tasks and activities.

SBugLocater: Bug Localization Based on Deep Matching and Information Retrieval

Bug localization is a technology that locates buggy source files using bug reports reported by users. Automatic localization of buggy files can speed up the process of bug fixing to improve the efficiency and productivity of software quality assurance teams. Nowadays, some research studies have investigated the natural language information retrieval technology, but few of them have applied the matching technology in deep learning to bug localization. Therefore, we propose a bug localization model SBugLocater based on deep matching and IR. The model composes of three layers: semantic matching layer, relevance matching layer, and IR layer. In particular, the relevance matching layer captures fine-grained local matching signals, while coarse-grained semantic similarity signals come from the semantic matching layer. Further, based on collaborative filtering in different directions, the IR layer works to find whether bug reports and source files are related, which indirectly transforms the matching task of different grammatical structures between bug reports and source files into the same structure and solves the mismatching problem of the first two matching models when the query is short. In our work, four benchmark data sets are used as experimental data sets and Accuracy@k, MAP, and MRR as evaluation metrics, which are used to compare and analyze the performance of bug localization with the four state-of-the-art methods. Experimental results show that SBugLocater outperforms the four models. For example, compared with the best of the four models, the evaluation metrics of Accuracy@10, MAP, and MRR are improved by 6.9%, 13.9%, and 17%, respectively.

FIXME: synchronize with database! An empirical study of data access self-admitted technical debt

Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.

Summary of the Third International Workshop on Bots in Software Engineering (BotSE 2021)

Bots automate tasks in software engineering projects and interact with software developers. Bots have been proposed, for example, for testing, maintenance, and automating bug fixes. The research community has been discussing these bots in the International Workshop on Bots in Software Engineering (BotSE), collocated with ICSE (the International Conference on Software Engineering). The workshop participants share experiences and challenges, discuss new usages of bots, and map out future directions. In this paper, we present a summary of the 3rd edition of the workshop, which comprised nine papers, one journal-first presentation, and two keynotes, followed by extensive discussion. More details can be found at http://botse.org/

A fine-grained data set and analysis of tangling in bug fixing commits

ContextTangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs.ObjectiveWe want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits.MethodsWe use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus.ResultsWe estimate that between 17% and 32% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66% to 87%. We find that about 11% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3% to 47% of data is noisy without manual untangling, depending on the use case.ConclusionTangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise.

Tracking Code Bug Fix Ripple Effects Based on Change Patterns Using Markov Chain Models

Change impact analysis evaluates the changes that are made in the software and finds the ripple effects, in other words, finds the affected software components. Code changes and bug fixes can have a high impact on code quality by introducing new vulnerabilities or increasing their severity. A recent high-visibility example of this is the code changes in the log4j web software CVE-2021-45105 to fix known vulnerabilities by removing and adding method called change types. This bug fix process exposed further code security concerns. In this article, we analyze the most common set of bug fix change patterns to have a better understanding of the distribution of software changes and their impact on code quality. To achieve this, we implemented a tool that compares two versions of the code and extracts the changes that have been made. Then, we investigated how these changes are related to change impact analysis. In our case study, we identified the change types for bug-inducing and bug fix changes using the Quixbugs dataset. Furthermore, we used 13 of the projects and 621 bugs from Defects4J to identify the common change types in bug fixes. Then, to find the change types that cause an impact on the software, we performed an impact analysis on a subset of projects and bugs of Defects4J. The results have shown that, on average, 90% of the bug fix change types are adding a new method declaration and changing the method body. Then, we investigated if these changes cause an impact or a ripple effect in the software by performing a Markov chain-based change impact analysis. The results show that the bug fix changes had only impact rates within a range of 0.4–5%. Furthermore, we performed a statistical correlation analysis to find if any of the bug fixes have a significant correlation with the impact of change. The results have shown that there is a negative correlation between caused impact with the change types adding new method declaration and changing method body. On the other hand, we found that there is a positive correlation between caused impact and changing the field type.

Update with care: Testing candidate bug fixes and integrating selective updates through binary rewriting

Enterprise software updates depend on the interaction between user and developer organizations. This interaction becomes especially complex when a single developer organization writes software that services hundreds of different user organizations. Miscommunication during patching and deployment efforts lead to insecure or malfunctioning software installations. While developers oversee the code, the update process starts and ends outside their control. Since developer test suites may fail to capture buggy behavior finding and fixing these bugs starts with user generated bug reports and 3rd party disclosures. The process ends when the fixed code is deployed in production. Any friction between user, and developer results in a delay patching critical bugs.Two common causes for friction are a failure to replicate user specific circumstances that cause buggy behavior and incompatible software releases that break critical functionality. Existing test generation techniques are insufficient. They fail to test candidate patches for post-deployment bugs and to test whether the new release adversely effects customer workloads. With existing test generation and deployment techniques, users cannot choose (nor validate) compatible portions of new versions and retain their previous version’s functionality.We present two new technologies to alleviate this friction. First, Test Generation for Ad Hoc Circumstances transforms buggy executions into test cases. Second, Binary Patch Decomposition allows users to select the compatible pieces of update releases. By sharing specific context around buggy behavior and developers can create specific test cases that demonstrate if their fixes are appropriate. When fixes are distributed by including extra context users can incorporate only updates that guarantee compatibility between buggy and fixed versions.We use change analysis in combination with binary rewriting to transform the old executable and buggy execution into a test case including the developer’s prospective changes that let us generate and run targeted tests for the candidate patch. We also provide analogous support to users, to selectively validate and patch their production environments with only the desired bug-fixes from new version releases.This paper presents a new patching workflow that allows developers to validate prospective patches and users to select which updates they would like to apply, along with two new technologies that make it possible. We demonstrate our technique constructs tests cases more effectively and more efficiently than traditional test case generation on a collection of real world bugs compared to traditional test generation techniques, and provides the ability for flexible updates in real world scenarios.

Golden Mutator Recommendation Based on Mutation Pattern Mining

Mutation testing is widely used in the research of evaluation and optimization of test set quality, and has been paid attention to the study of bug localization and fixing. But one inherent problem of mutation testing is huge computation cost. Selective mutation is an important method to reduce mutation testing cost. However, the existing selective mutation researches indicate that there is no universal selection strategy. This paper proposes a method which integrates with historical software data mining to recommend suitable mutator for program under test. The basic idea of the method is in the software version control system, any pair of nonfixed and post-fixed programs can be original program and mutant of each other. The edit performed during bug fixing contains mutators, and such mutator can guide buggy program to correct program, hence it is called Golden Mutator. The basic method is to compare the buggy files and the corresponding fixed files in the version control system, obtain historical faulty statements and their fix editing operations, thereby accumulating the bug-fix instance base, and then mining mutation patterns from it. Before mutating the target statement, we first find out faulty instances similar to the target statement, and use their fixing edits to match with the mutation pattern, so as to get the golden mutator applicable to the target statement. This paper uses Defects4j dataset in the test, verifies the accuracy of the proposed recommendation method, and further uses the method in bug localization. Compared to fixedly selected mutators, when applying the golden mutator recommended by using the proposed method, the average accuracy of bug localization is higher.

Machine learning‐based test oracles for performance testing of cyber‐physical systems: An industrial case study on elevators dispatching algorithms

AbstractThe software of systems of elevators needs constant maintenance to deal with new functionality, bug fixes, or legislation changes. To automatically validate the software of these systems, a typical approach in industry is to use regression oracles, which execute test inputs both in the software version under test and in a previous software version. However, these practices require a long test execution time and cannot be re‐used at different test phases. To deal with these issues, we propose Dispatching AlgoRIthm Oracle (DARIO), a test oracle that relies on regression machine‐learning algorithms to detect both functional and non‐functional problems of the system. The machine‐learning algorithms of this oracle are trained by using data from previously tested versions to predict reference functional and non‐functional performance values of the new versions. An empirical evaluation with an industrial case study demonstrates the feasibility of using our approach. A total of five regression learning algorithms were validated by using mutation testing techniques. For the context of functional bugs, the accuracy when predicting verdicts by DARIO ranged between 95% and 98%, across the different scenarios proposed. For the context of non‐functional bugs, were competitive too, having an accuracy when predicting verdicts by DARIO ranged between 83% and 87%.

Deep specification and proof preservation for the CoqTL transformation language

Executable engines for relational model-transformation languages evolve continuously because of language extension, performance improvement and bug fixes. While new versions generally change the engine semantics, end-users expect to get backward-compatibility guarantees, so that existing transformations do not need to be adapted at every engine update. The CoqTL model-transformation language allows users to define model transformations, theorems on their behavior and machine-checked proofs of these theorems in Coq. Backward-compatibility for CoqTL involves also the preservation of these proofs. However, proof preservation is challenging, as proofs are easily broken even by small refactorings of the code they verify. In this paper, we present the solution we designed for the evolution of CoqTL. We provide a deep specification of the transformation engine, including a set of theorems that must hold against the engine implementation. Then, at each milestone in the engine development, we certify the new version of the engine against this specification, by providing proofs of the impacted theorems. The certification formally guarantees end-users that all the proofs they write using the provided theorems will be preserved through engine updates. We illustrate the structure of the deep specification theorems, we produce a machine-checked certification of three versions of CoqTL against it, and we show examples of user proofs that leverage this specification and are thus preserved through the updates. Finally, we discuss the evolution of the deep specification by an extension mechanism, we present an evolution that introduces trace links in the specification, and we show which user proofs are preserved through specification evolutions.

Multi-Dimension Convolutional Neural Network for Bug Localization

Software bugs remain frequent in the life cycle of software development and maintenance. Automatic localization of buggy source code files is critical for timely bug fixing and improving the efficiency of software quality assurance. Various bug localization techniques have been proposed using different dimensions of features. Recent studies have shown that different dimensions of features may play different roles in bug localization. Unfortunately, how to effectively merge these dimensions of features for improving bug localization has rarely been investigated. This article presents a Multi-Dimension Convolutional Neural Network (MD-CNN) model for bug localization automatically based on a bug report. Our approach has dual-novelty. First, we identify and extract five statistical dimensions of features. Second, we design a Convolutional Neural Network (CNN) model that takes our five statistical dimensions of features as the input and iteratively learns the complex and non-linear relationship between the features and the bug locations. The MD-CNN bug localization model is verified using six large-scale open source projects. The experimental results show that our MD-CNN outperforms the existing representative bug localization techniques in terms of the Mean Average Precision (MAP) and the number of bugs successfully localized in the top 1, 5, and 10 matched source code files.

Collaboration in software ecosystems: A study of work groups in open environment

As a particular type of software ecosystem, an open source software ecosystem (OSSECO) is a collection of interdependent open source software (OSS) projects which are developed and evolve together. Events happening within an OSSECO inherently involve the collaboration of participants from multiple OSS projects, forming a temporary work group. However, it is still unclear how different members of a work group collaborate to fix cross-project bugs, a typical event in the maintenance of OSSECOs. This study aims to investigate the characteristics of collaboration within a work group when fixing cross-project bugs in an OSSECO. It involves the participants from the upstream (which caused the bugs) and the downstream (which were affected by the bugs) OSS projects. We conducted our study on 236 cross-project bugs from the scientific Python ecosystem, involving 571 participants and 91 OSS projects, to understand open collaboration within a work group. We established a quantitative analysis to investigate the members of a work group, along with a qualitative analysis to understand the roles of the members from different OSS communities. The results show that: (1) A typical work group is constituted of four to eight members from the core development teams of the two OSS communities. More members concern with the upstream OSS projects and few can make active contributions to both sides; (2) Distinct responsibilities are taken by the two OSS communities, with the downstream members as the problem-finders and the upstream members as the decision-makers or gatekeepers. Our findings reveal the collaborative mechanism and the responsibility allocation between the upstream and downstream OSS communities in the ecosystems. • A study on 236 cross-project bug fixing activities to understand open collaboration in open source software ecosystems. • Six findings that reveal the members of a cross-project bug fixing work group. • Five findings that summarize the roles of cross-project bug fixing group members. • Recommendations to the researchers, developers, and practitioners.

Clones in deep learning code: what, where, and why?

Deep Learning applications are becoming increasingly popular worldwide. Developers of deep learning systems like in every other context of software development strive to write more efficient code in terms of performance, complexity, and maintenance. The continuous evolution of deep learning systems imposing tighter development timelines and their increasing complexity may result in bad design decisions by the developers. Besides, due to the use of common frameworks and repetitive implementation of similar tasks, deep learning developers are likely to use the copy-paste practice leading to clones in deep learning code. Code clone is considered to be a bad software development practice since developers can inadvertently fail to properly propagate changes to all clones fragments during a maintenance activity. However, to the best of our knowledge, no study has investigated code cloning practices in deep learning development. The majority of research on deep learning systems mostly focusing on improving the dependability of the models. Given the negative impacts of clones on software quality reported in the studies on traditional systems and the inherent complexity of maintaining deep learning systems (e.g., bug fixing), it is very important to understand the characteristics and potential impacts of code clones on deep learning systems. This paper examines the frequency, distribution, and impacts of code clones and the code cloning practices in deep learning systems. To accomplish this, we use the NiCad clone detection tool to detect clones from 59 Python, 14 C#, and 6 Java based deep learning systems and an equal number of traditional software systems. We then analyze the comparative frequency and distribution of code clones in deep learning systems and the traditional ones. Further, we study the distribution of the detected code clones by applying a location based taxonomy. In addition, we study the correlation between bugs and code clones to assess the impacts of clones on the quality of the studied systems. Finally, we introduce a code clone taxonomy related to deep learning programs based on 6 DL software systems (from 59 DL systems) and identify the deep learning system development phases in which cloning has the highest risk of faults. Our results show that code cloning is a frequent practice in deep learning systems and that deep learning developers often clone code from files contain in distant repositories in the system. In addition, we found that code cloning occurs more frequently during DL model construction, model training, and data pre-processing. And that hyperparameters setting is the phase of deep learning model construction during which cloning is the riskiest, since it often leads to faults.

Prioritizing user concerns in app reviews – A study of requests for new features, enhancements and bug fixes

: App developers spend exhaustive manual efforts towards the identification and prioritization of informative end-user reviews. Informative reviews are those that express end-users’ requests for new features, bug fixes and possible enhancements. Problem Statement : While prior studies have proposed approaches to convert app reviews into actionable knowledge , these are limited in utility due to being domain knowledge dependent or manually-based. : In this study, in order to facilitate app maintenance and evolution cycles, we develop two novel automated prioritization techniques to rank informative reviews, and also compare their performances. : We developed the techniques comprising of entropy, frequency, TF-IDF and sentiment scoring methods using reviews from four popular apps comprising more than 1000 informative reviews in each app. Time and accuracy metrics were then used to measure the performance of our techniques. We performed evaluations where the ranking outcomes generated by our techniques were compared to those provided by regular app users and developers using two rounds of evaluations (internal and external evaluations). : Our results show that the time required for prioritization was in the range of 17–25 s and the accuracy of prioritization was in the range of 73–90%. : These are promising outcomes when compared to prior work, where our outcomes were 4% and 185% better in terms of accuracy and time respectively. Thus, it is anticipated that our proposed techniques could support app developers in identifying and prioritizing informative reviews.

Analysing high-throughput sequencing data in Python with HTSeq 2.0.

SummaryHTSeq 2.0 provides a more extensive application programming interface including a new representation for sparse genomic data, enhancements for htseq-count to suit single-cell omics, a new script for data using cell and molecular barcodes, improved documentation, testing and deployment, bug fixes and Python 3 support.Availability and implementationHTSeq 2.0 is released as an open-source software under the GNU General Public License and is available from the Python Package Index at https://pypi.python.org/pypi/HTSeq. The source code is available on Github at https://github.com/htseq/htseq.Supplementary information Supplementary data are available at Bioinformatics online.

Visualizing the customization endeavor in product-based-evolving software product lines: a case of action design research

Software Product Lines (SPLs) aim at systematically reusing software assets, and deriving products (a.k.a., variants) out of those assets. However, it is not always possible to handle SPL evolution directly through these reusable assets. Time-to-market pressure, expedited bug fixes, or product specifics lead to the evolution to first happen at the product level, and to be later merged back into the SPL platform where the core assets reside. This is referred to as product-based evolution. In this scenario, deciding when and what should go into the next SPL release is far from trivial. Distinct questions arise. How much effort are developers spending on product customization? Which are the most customized core assets? To which extent is the core asset code being reused for a given product? We refer to this endeavor as Customization Analysis, i.e., understanding the functional increments in adjusting products from the last SPL platform release. The scale of the SPLs’ code-base calls for customization analysis to be conducted through Visual Analytics tools. This work addresses the design principles for such tools through a joint effort between academia and industry, specifically, Danfoss Drives, a company division in charge of the P400 SPL. Accordingly, we adopt an Action Design Research approach where answers are sought by interacting with the practitioners in the studied situations. We contribute by providing informed goals for customization analysis as well as an intervention in terms of a visual analytics tool. We conclude by discussing to what extent this experience can be generalized to product-based evolving SPL organizations other than Danfoss Drives.

Breaking bad? Semantic versioning and impact of breaking changes in Maven Central

Just like any software, libraries evolve to incorporate new features, bug fixes, security patches, and refactorings. However, when a library evolves, it may break the contract previously established with its clients by introducing Breaking Changes (BCs) in its API. These changes might trigger compile-time, link-time, or run-time errors in client code. As a result, clients may hesitate to upgrade their dependencies, raising security concerns and making future upgrades even more difficult. Understanding how libraries evolve helps client developers to know which changes to expect and where to expect them, and library developers to understand how they might impact their clients. In the most extensive study to date, Raemaekers et al. investigate to what extent developers of Java libraries hosted on the Maven Central Repository (MCR) follow semantic versioning conventions to signal the introduction of BCs and how these changes impact client projects. Their results suggest that BCs are widespread without regard for semantic versioning, with a significant impact on clients. In this paper, we conduct an external and differentiated replication study of their work. We identify and address some limitations of the original protocol and expand the analysis to a new corpus spanning seven more years of the MCR. We also present a novel static analysis tool for Java bytecode, Maracas, which provides us with: (i) the set of all BCs between two versions of a library, and; (ii) the set of locations in client code impacted by individual BCs. Our key findings, derived from the analysis of 119,879 library upgrades and 293,817 clients, contrast with the original study and show that 83.4% of these upgrades do comply with semantic versioning. Furthermore, we observe that the tendency to comply with semantic versioning has significantly increased over time. Finally, we find that most BCs affect code that is not used by any client, and that only 7.9% of all clients are affected by BCs. These findings should help (i) library developers to understand and anticipate the impact of their changes; (ii) library users to estimate library upgrading effort and to pick libraries that are less likely to break, and; (iii) researchers to better understand the dynamics of library-client co-evolution in Java.

Revisiting the building of past snapshots \u2014 a replication and reproduction study

ContextBuilding past source code snapshots of a software product is necessary both for research (analyzing the past state of a program) and industry (increasing trustability by reproducibility of past versions, finding bugs by bisecting, backporting bug fixes, among others). A study by Tufano et al. showed in 2016 that many past snapshots cannot be built.ObjectiveWe replicate Tufano et al.’s study in 2020, to verify its results and to study what has changed during this time in terms of compilability of a project. Also, we extend it by studying a different set of projects, using additional techniques for building past snapshots, with the aim of extending the validity of its results.Method(i) Replication of the original study, obtaining past snapshots from 79 repositories (with a total of 139,389 commits); and (ii) Reproduction of the original study on a different set of 80 large Java projects, extending the heuristics for building snapshots (300,873 commits).ResultsWe observed degradation of compilability over time, due to vanishing of dependencies and other external artifacts. We validated that the most influential error causing failures in builds are missing external artifacts, and the less influential is compiling errors. We observed some facts that could lead to the effect of the build tool on past compilability.ConclusionsWe provide details on what aspects have a strong and a shallow influence on past compilability, giving ideas of how to improve it. We could extend previous research on the matter, but could not validate some of the previous results. We offer recommendations on how to make this kind of studies more replicable.

Characterizing duplicate bugs: Perceptions of practitioners and an empirical analysis

AbstractBug handling is an essential part of the software development process. Ideally, in a bug‐tracking system, bugs are reported, fixed, verified, and closed. In some cases, bugs have to be reopened mostly due to an incorrect fix. However, instead of reopening the existing bug report, users may submit a new report for a previously reported bug, which results in duplicate bug reports. Users might report duplicate bugs if they miss the previous bug report or if the previous bug is unresolved (i.e., in progress) and therefore cannot be reopened. These duplicate bug reports may cost extra maintenance efforts in triaging and bug fixing. There have been several studies on characterizing reopened bugs and duplicate bug reports; however, to the best of our knowledge, there has been no prior work on understanding the dynamics of their interaction, which is missed reopen bugs. Our study is based on analyzing the difference between duplicate and nonduplicate bugs and further categorizing the duplicate bugs. In this regard, we categorize duplicate bugs according to the original bug's resolution status at the duplicate's creation time as Master‐Unresolved bugs and Master‐Resolved (Missed Reopen) bugs to distinguish their properties. We compare these two types of bugs in terms of their relationship to their master bug, bug surface time, bug fix time, bug's severity, and the number of users involved. We perform case studies using the Eclipse and Mozilla projects' bug repositories that include more than 165,500 and 394,000 bug reports, respectively. Additionally, we investigate the perceived importance, impact, and causes of duplicate bugs, as well as the difference between nonduplicate and duplicate bugs and its categories for practitioners in the software industry by conducting a survey.