E XPOSITOR : Scriptable Time-Travel Debugging with First Class Traces Khoo Yit Phang, Jeffrey S. Foster, and Michael Hicks Computer Science Department, University of Maryland, College Park Email: { khooyp,jfoster,mwh } @cs.umd.edu While we could have employed the same debugging strategy Abstract —We present E XPOSITOR , a new debugging environ- ment that combines scripting and time-travel debugging to allow by altering the program itself (e.g., by inserting print state- developers to automate complex debugging tasks. The fundamen- ments and assertions), doing so would require recompilation— tal abstraction provided by E XPOSITOR is the execution trace , and that can take considerable time for large programs (e.g., which is a time-indexed sequence of program state snapshots. Firefox), thus greatly slowing the rate of hypothesis testing. Developers can manipulate traces as if they were simple lists with Modifying a program can also change its behavior—we have operations such as map and filter. Under the hood, E XPOSITOR efficiently implements traces as lazy, sparse interval trees, whose all experienced the frustration of inserting a debugging print contents are materialized on demand. E XPOSITOR also provides statement only to make the problem disappear! Scripts also a novel data structure, the edit hash array mapped trie , which is a have the benefit that they can invoke to libraries not used by lazy implementation of sets, maps, multisets, and multimaps that the program itself, and may be reused in other contexts. enables developers to maximize the efficiency of their debugging scripts. We have used E XPOSITOR to debug a stack overflow Background: Prior scriptable debuggers. There has been and to unravel a subtle data race in Firefox. We believe that considerable prior work on scriptable debugging. GDB’s E XPOSITOR represents an important step forward in improving Python interface makes GDB’s interactive commands— the technology for diagnosing complex, hard-to-understand bugs. stepping, setting breakpoints, etc.—available in a general- purpose programming language. However, this interface em- ploys a callback-oriented programming style which, as pointed I. I NTRODUCTION out by Marceau et al. [2], reduces composability and reusabil- “...we talk a lot about finding bugs, but really, ity, and complicates checking temporal properties. Marceau [Firefox’s] bottleneck is not finding bugs but fixing et al. propose treating the program as an event generator— [them]...” each function call, memory reference, etc. can be thought of —Robert O’Callahan 1 as an event—and scripts are written in the style of functional “[In debugging,] understanding how the failure reactive programming (FRP) [3]. While FRP-style debugging came to be...requires by far the most time and other solves the problems of callback-based programming, it has a resources” key limitation: time always marches forward, so we cannot ask —Andreas Zeller [1] questions about prior states. For example, if while debugging a program we find a doubly-freed address, we cannot jump Debugging program failures is an inescapable task for backward in time to find the corresponding malloc . Instead software developers. Understanding a failure involves repeated we would need to rerun the program from scratch to find that application of the scientific method: the programmer makes call, which may be problematic if there is any nondeterminism, some observations; proposes a hypothesis as to the cause of e.g., if the addresses returned by malloc differ from run to run. the failure; uses this hypothesis to make predictions about the We could instead prospectively gather the addresses returned program’s behavior; tests those predictions using experiments; by malloc as the program runs, but then we would need to and finally either declares victory or repeats the process with record all such calls up to the erroneous free . a new or refined hypothesis. Time-travel debuggers, like UndoDB [4], and systems for Scriptable debugging is a powerful technique for hypothesis capturing entire program executions, like Amber [5], allow a testing in which programmers write scripts to perform complex single nondeterministic execution to be examined at multiple debugging tasks. For example, suppose we observe a bug points in time. Unfortunately, scriptable time-travel debuggers involving a cleverly implemented set data structure. We can typically use callback-style programming, with all its prob- try to debug the problem by writing a script that maintains lems. (Sec. VI discusses prior work in detail.) a shadow data structure that implements the set more simply E XPOSITOR : Scriptable, time-travel debugging. In this (e.g., as a list). We run the buggy program, and the script tracks paper, we present E XPOSITOR , a new scriptable debugging the program’s calls to insert and remove , stopping execution system inspired by FRP-style scripting but with the advantages when the contents of the shadow data structure fail to match of time-travel debugging. E XPOSITOR scripts treat a program’s those of the buggy one, helping pinpoint the underlying fault. execution trace as a (potentially infinite) list of time-annotated 1 http://vimeo.com/groups/lfx/videos/12471856, at 27:15 program state snapshots. Scripts can manipulate traces using
Recommend
More recommend
