Automatic Software Repair: a Bibliography

This article presents a survey on automatic software repair. Automatic software repair consists of automatically finding a solution to software bugs without human intervention. This article considers all kinds of repairs. First, it discusses behavioral repair where test suites, contracts, models, and crashing inputs are taken as oracle. Second, it discusses state repair, also known as runtime repair or runtime recovery, with techniques such as checkpoint and restart, reconfiguration, and invariant restoration. The uniqueness of this article is that it spans the research communities that contribute to this body of knowledge: software engineering, dependability, operating systems, programming languages, and security. It provides a novel and structured overview of the diversity of bug oracles and repair operators used in the literature

Automatic Detection, Validation and Repair of Race Conditions in Interrupt-Driven Embedded Software

Interrupt-driven programs are widely deployed in safety-critical embedded systems to perform hardware and resource dependent data operation tasks. The frequent use of interrupts in these systems can cause race conditions to occur due to interactions between application tasks and interrupt handlers (or two interrupt handlers). Numerous program analysis and testing techniques have been proposed to detect races in multithreaded programs. Little work, however, has addressed race condition problems related to hardware interrupts. In this paper, we present SDRacer, an automated framework that can detect, validate and repair race conditions in interrupt-driven embedded software. It uses a combination of static analysis and symbolic execution to generate input data for exercising the potential races. It then employs virtual platforms to dynamically validate these races by forcing the interrupts to occur at the potential racing points. Finally, it provides repair candidates to eliminate the detected races. We evaluate SDRacer on nine real-world embedded programs written in C language. The results show that SDRacer can precisely detect and successfully fix race conditions.Comment: This is a draft version of the published paper. Ke Wang provides suggestions for improving the paper and README of the GitHub rep

Understanding Concurrency Vulnerabilities in Linux Kernel

While there is a large body of work on analyzing concurrency related software bugs and developing techniques for detecting and patching them, little attention has been given to concurrency related security vulnerabilities. The two are different in that not all bugs are vulnerabilities: for a bug to be exploitable, there needs be a way for attackers to trigger its execution and cause damage, e.g., by revealing sensitive data or running malicious code. To fill the gap, we conduct the first empirical study of concurrency vulnerabilities reported in the Linux operating system in the past ten years. We focus on analyzing the confirmed vulnerabilities archived in the Common Vulnerabilities and Exposures (CVE) database, which are then categorized into different groups based on bug types, exploit patterns, and patch strategies adopted by developers. We use code snippets to illustrate individual vulnerability types and patch strategies. We also use statistics to illustrate the entire landscape, including the percentage of each vulnerability type. We hope to shed some light on the problem, e.g., concurrency vulnerabilities continue to pose a serious threat to system security, and it is difficult even for kernel developers to analyze and patch them. Therefore, more efforts are needed to develop tools and techniques for analyzing and patching these vulnerabilities.Comment: It was finished in Oct 201

Architecture Smells vs. Concurrency Bugs: an Exploratory Study and Negative Results

Technical debt occurs in many different forms across software artifacts. One such form is connected to software architectures where debt emerges in the form of structural anti-patterns across architecture elements, namely, architecture smells. As defined in the literature, ``Architecture smells are recurrent architectural decisions that negatively impact internal system quality", thus increasing technical debt. In this paper, we aim at exploring whether there exist manifestations of architectural technical debt beyond decreased code or architectural quality, namely, whether there is a relation between architecture smells (which primarily reflect structural characteristics) and the occurrence of concurrency bugs (which primarily manifest at runtime). We study 125 releases of 5 large data-intensive software systems to reveal that (1) several architecture smells may in fact indicate the presence of concurrency problems likely to manifest at runtime but (2) smells are not correlated with concurrency in general -- rather, for specific concurrency bugs they must be combined with an accompanying articulation of specific project characteristics such as project distribution. As an example, a cyclic dependency could be present in the code, but the specific execution-flow could be never executed at runtime

Producing Scheduling that Causes Concurrent Programs to Fail

A noise maker is a tool that seeds a concurrent program with conditional synchronization primitives (such as yield()) for the purpose of increasing the likelihood that a bug manifest itself. This work explores the theory and practice of choosing where in the program to induce such thread switches at runtime. We introduce a novel fault model that classifies locations as .good., .neutral., or .bad,. based on the effect of a thread switch at the location. Using the model we explore the terms in which efficient search for real-life concurrent bugs can be carried out. We accordingly justify the use of probabilistic algorithms for this search and gain a deeper insight of the work done so far on noise-making. We validate our approach by experimenting with a set of programs taken from publicly available multi-threaded benchmark. Our empirical evidence demonstrates that real-life behavior is similar to what our model predicts

Vertically integrated analysis and transformation for embedded software

Journal ArticleProgram analyses and transformations that are more aggressive and more domain-specific than those traditionally performed by compilers are one possible route to achieving the rapid creation of reliable and efficient embedded software. We are creating a new framework for Vertically Integrated Program Analysis (VIPA) that makes use of information gathered at multiple levels of abstraction such as high-level models, source code, and assembly language. This paper describes our approach and shows how and why it will help create better embedded software

Reactive Programming with Swift Combine:An Analysis of Problems Faced by Developers on Stack Overflow

Reactive programming is a programming paradigm that enables systems to automatically react to changes in data or events in a responsive and asynchronous manner, leveraging the concept of streams. The adoption of reactive programming techniques has grown significantly, particularly in developing mobile applications that demand efficient frameworks for creating adaptable and scalable systems. An example of such a framework is Combine, introduced by Apple in 2019 for Swift application development on the iOS platform. A framework that is worth mentioning is Combine, which was introduced by Apple in 2019 for Swift application development on the iOS platform. However, transitioning from imperative to reactive paradigms presents complex challenges for developers. This study aims to address the research gap that exists in Swift Combine by identifying and understanding the key challenges faced by developers when adopting and using that framework. Using a data mining approach, we analyzed questions and accepted answers from Stack Overflow related to Combine usage. Employing topic modeling with Latent Dirichlet Allocation, our analysis revealed 14 topics related to Combine usage, highlighting the most relevant and challenging aspects. These findings provide valuable insights for developers learning or incorporating Combine into their applications and serve as a reference for future studies in the field.</p