BugRedux: Reproducing field failures for in-house debugging

Abstract

Abstract-A recent survey conducted among developers of the Apache, Eclipse, and Mozilla projects showed that the ability to recreate field failures is considered of fundamental importance when investigating bug reports. Unfortunately, the information typically contained in a bug report, such as memory dumps or call stacks, is usually insufficient for recreating the problem. Even more advanced approaches for gathering field data and help in-house debugging tend to collect either too little information, and be ineffective, or too much information, and be inefficient. To address these issues, we present BUGREDUX, a novel general approach for in-house debugging of field failures. BUGREDUX aims to synthesize, using execution data collected in the field, executions that mimic the observed field failures. We define several instances of BUGREDUX that collect different types of execution data and perform, through an empirical study, a cost-benefit analysis of the approach and its variations. In the study, we apply BUGREDUX to 16 failures of 14 real-world programs. Our results are promising in that they show that it is possible to synthesize in-house executions that reproduce failures observed in the field using a suitable set of execution data.

Auto-completing bug reports for Android applications

“…A body of work known as in-field failure reproduction [20,43,77,30,42,16,44,27] shares similar goals with our approach. These techniques collect run-time information (e.g., execution traces) from instrumented programs that provide developers with a better understanding of the causes of an in-field failure, which will subsequently help expedite the fixing of those failures.…”

KATCH: high-coverage testing of software patches

“…Similarly, generating inputs with the same effect as a crashing input but which do not leak sensitive data, is used in bug reporting to preserve user privacy [9]. In the context of automated debugging, execution synthesis [44] and BugRedux [23] attempt to solve a similar problem: generating an input or a path starting from a set of 'waypoints' through which execution has to pass.…”

Regression tests to expose change interaction errors

“…If the character is a digit, then the number is read into value v. In the changed version a boolean lhs is set to true (lines [4][5]. If the character is a dash, the variable init is computed using v (lines [7][8]. If the end of the line is reached, the bug is observable if init is 0 (line 10).…”

“…In order to explore change sequences our approach builds and extends previous work that deals with reaching statements in a program. However, these tools seek to reach a single statement [13,23], a set of statements [9], or a sequence of statements [8] instead of a graph. To overcome this problem we have modified the Otter tool [9] to take a graph of statements as input and target multiple statements along this graph structure at once.…”