Software product faults are an inevitable and an undesirable byproduct of any software development. Often hard to detect they are a major contributing factor to the overall development and support costs and a source of technical risk for the application as a whole. The criticality of the impact has resulted in several decades of non-stop iterative improvements, aimed at avoiding and detecting the faults through development and application of sophisticated automated testing and validation systems, Finding the exact source of error, creating a patch to fix it and validating it for production release is still a highly manual activity. In this paper we build upon the theoretical framework of relative correctness, which we have laid out in our previous work, and present a massively parallel automated tool implementing it in order to support root cause analysis and patch generation.

To repair a program does not mean to make it absolutely correct; it only means to make it more-correct, in some sense, than it is. This distinction has consequences: Given that software products typically have a dozen faults per KLOC and thousands of KLOC’s, program repair tools ought to be designed in such a way as to transform an incorrect program into an incorrect, albeit more-correct, program. In the absence of a concept of relative correctness (the property of a program to be more-correct than another with respect to a specification), program repair methods have resorted to various approximations of absolute correctness. This shortcoming has been concealed by the fact that they are usually validated on programs with a single fault at a time, for which the goals of absolute correctness and relative correctness are indistinguishable. In this paper we discuss how the use of relative correctness can reduce the scale of patch generation and enhance the efficiency, precision and recall of patch validation.

Given that faults are the focus of much software quality assurance (fault avoidance, fault removal, fault tolerance, fault prediction/ forecasting), we argue that a formal definition of faults ought to help us enhance the state of the art in this field. In this paper we consider a formal semantic definition of faults, and explore the insights that this definition gives us, and how these insights can be used in practice. Some of these insights are counter-intuitive, which makes them all the more interesting/useful.

Program repair has been an active research area for over a decade and has achieved great strides in terms of scalable automated repair tools. In this paper we argue that existing program repair tools lack an important ingredient, which limits their scope and their efficiency: a formal definition of a fault, and a formal characterization of fault removal. To support our conjecture, we consider GenProg, an archetypical program repair tool, and modify it according to our definitions of fault and fault removal; then we show, by means of empirical experiments, the impact that this has on the effectiveness and efficiency of thee tool.