In data processing, datasets are expected to adhere to specific formats. However, inconsistencies due to human error, data corruption, or partial transmission can render these datasets nonconforming, hindering automated processing. This necessitates manual data repair, a time-consuming and errorprone task, especially when formal specifications are unavailable. To address this challenge, we introduce $\epsilon$REPAIR, a novel format-free approach to automating data repair. $\epsilon$REPAIR leverages parser feedback to detect and correct data inconsistencies, making it a versatile solution for data cleansing. In evaluation, $\epsilon$REPAIR achieves $2.6 \times$ higher-quality repairs than its closest competitor, DDMax, in terms of the number of edits required to restore corrupted data, while reducing data loss by $2.8 \times$ compared to DDMax, with only $1.4 \times$ runtime overhead. This work presents a practical, robust, and flexible formatfree data repair alternative to DDMax. Its applications extend to domains such as data science, software development, and other human-centric systems, where handling diverse and inconsistent datasets is critical.

To effectively test complex software, it is important to generategoal-specific inputs, i.e., inputs that achieve a specific testing goal. For instance, developers may intend to target one or more testing goal(s) during testing – generate complex inputs or trigger new or error-prone behaviors.Problem:However, most state-of-the-art test generators are not designed totarget specific goals. Notably, grammar-based test generators, which (randomly) producesyntactically valid inputsvia an input specification (i.e., grammar) have a low probability of achieving an arbitrary testing goal.Aim: This work addresses this challenge by proposing an automated test generation approach (calledFDLOOP) which iteratively learns relevant input properties from existing inputs to drive the generation of goal-specific inputs.Method: The main idea of our approach is to leveragetest feedbackto generategoal-specific inputsvia a combination ofevolutionary testing and grammar learning.FDLOOPautomatically learns a mapping between input structures and a specific testing goal, such mappings allow to generate inputs that target the goal-at-hand. Given a testing goal,FDLOOPiteratively selects, evolves and learn the input distribution of goal-specific test inputs via test feedback and a probabilistic grammar. We concretizeFDLOOPfor four testing goals, namely unique code coverage, input-to-code complexity, program failures (exceptions) and long execution time. We evaluateFDLOOPusing three (3) well-known input formats (JSON, CSS and JavaScript) and 20 open-source software.Results: In most (86%) settings,FDLOOPoutperforms all five tested baselines namely the baseline grammar-based test generators (random, probabilistic and inverse-probabilistic methods), EvoGFuzz and DynaMOSA.FDLOOPis (up to) twice (2X) as effective as the best baseline (EvoGFuzz) in inducing erroneous behaviors. In addition, we show that the main components ofFDLOOP(i.e., input mutator, grammar mutator and test feedbacks) contribute positively to its effectiveness. We also observed thatFDLOOPis effective across varying parameter settings – the number of initial seed inputs, the number of generated inputs, the number of input generations and varying random seed values.Implications: Finally, our evaluation demonstrates thatFDLOOPeffectively achieves single testing goals (revealing erroneous behaviors, generating complex inputs, or inducing long execution time) and scales to multiple testing goals.

Much research on automated program debugging often assumes that bug fix location(s) indicate the faults' root causes and that root causes of faults lie within single code elements (statements). It is also often assumed that the number of statements a developer would need to inspect before finding the first faulty statement reflects debugging effort. Although intuitive, these three assumptions are typically used (55% of experiments in surveyed publications make at least one of these three assumptions) without any consideration of their effects on the debugger's effectiveness and potential impact on developers in practice. To deal with this issue, we perform controlled experimentation, split testing in particular, using 352 bugs from 46 open-source C programs, 19 Automated Fault Localization (AFL) techniques (18 statistical debugging formulas and dynamic slicing), two (2) state-of-the-art automated program repair (APR) techniques (GenProg and Angelix) and 76 professional developers. Our results show that these assumptions conceal the difficulty of debugging. They make AFL techniques appear to be (up to 38%) more effective, and make APR tools appear to be (2X) less effective. We also find that most developers (83%) consider these assumptions to be unsuitable for debuggers and, perhaps worse, that they may inhibit development productivity. The majority (66%) of developers prefer debugging diagnoses without these assumptions twice as much as with the assumptions. Our findings motivate the need to assess debuggers conservatively, i.e., without these assumptions.

When a program fails to process an input, it need not be the program code that is at fault. It can also be that the input data is faulty, for instance as result of data corruption. To get the data processed, one then has to debug the input data---that is, (1) identify which parts of the input data prevent processing, and (2) recover as much of the (valuable) input data as possible. In this paper, we present a general-purpose algorithm called ddmax that addresses these problems automatically. Through experiments, ddmax maximizes the subset of the input that can still be processed by the program, thus recovering and repairing as much data as possible; the difference between the original failing input and the "maximized" passing input includes all input fragments that could not be processed. To the best of our knowledge, ddmax is the first approach that fixes faults in the input data without requiring program analysis. In our evaluation, ddmax repaired about 69% of input files and recovered about 78% of data within one minute per input.