How to Do a Million Watchpoints: Efficient Debugging Using Dynamic Instrumentation

Application debugging is a tedious but inevitable chore in any software development project. An effective debugger can make programmers more productive by allowing them to pause execution and inspect the state of the process, or monitor writes to memory to detect data corruption. The latter is a notoriously difficult category of bugs to diagnose and repair especially in pointer-heavy applications. The debugging challenges will increase with the arrival of multicore processors which require explicit parallelization of the user code to get any performance gains. Parallelization in turn can lead to more data debugging issues such as the detection of data races between threads. This paper leverages the increasing efficiency of runtime binary interpreters to provide a new concept of Efficient Debugging using Dynamic Instrumentation, or EDDI. The paper demonstrates for the first time the feasibility of using dynamic instrumentation on demand to accelerate software debuggers, especially when the available hardware support is lacking or inadequate. As an example, EDDI can simultaneously monitor millions of memory locations, without crippling the host processing platform. It does this in software and hence provides a portable debugging environment. It is also well suited for interactive debugging because of the low associated overheads. EDDI provides a scalable and extensible debugging framework that can substantially increase the feature set of standard off the shelf debuggers.Singapore-MIT Alliance (SMA

Ada User Guide for LEGO MINDSTORMS NXT

The purpose of this guide is to introduce the robotics kit LEGO MINDSTORMS NXT to the Ada community. All the steps required to complete a working Ada application running under the LEGO MINDSTORMS NXT are covered.

Automated Testing and Debugging for Big Data Analytics

The prevalence of big data analytics in almost every large-scale software system has generated a substantial push to build data-intensive scalable computing (DISC) frameworks such as Google MapReduce and Apache Spark that can fully harness the power of existing data centers. However, frameworks once used by domain experts are now being leveraged by data scientists, business analysts, and researchers. This shift in user demographics calls for immediate advancements in the development, debugging, and testing practices of big data applications, which are falling behind compared to the DISC framework design and implementation. In practice, big data applications often fail as users are unable to test all behaviors emerging from interleaving dataflow operators, user-defined functions, and framework's code. "Testing based on a random sample" rarely guarantees the reliability and "trial and error" and "print" debugging methods are expensive and time-consuming. Thus, the current practice of developing a big data application must be improved and the tools built to enhance the developer's productivity must adapt to the distinct characteristics of data-intensive scalable computing. By synthesizing ideas from software engineering and database systems, our hypothesis is that we can design effective and scalable testing and debugging algorithms for big data analytics without compromising the performance and efficiency of the underlying DISC framework. To design such techniques, we investigate how we can build interactive and responsive debugging primitives that significantly reduce the debugging time, yet do not pose much performance overhead on big data applications. Furthermore, we investigate how we can leverage data provenance techniques from databases and fault-isolation algorithms from software engineering to pinpoint the minimal subset of failure-inducing inputs efficiently. To improve the reliability of big data analytics, we investigate how we can abstract the semantics of dataflow operators and use them in tandem with the semantics of user-defined functions to generate a minimum set of synthetic test inputs capable of revealing more defects than the entire input dataset.To examine the first hypothesis, we introduce interactive, real-time debugging primitives for big data analytics through innovative and scalable debugging features such as simulated breakpoint, dynamic watchpoint, and crash culprit identification. Second, we design a new automated fault localization approach that combines insights from both the software engineering and database literature to bring delta debugging closer to a reality in the big data applications by leveraging data provenance and by constructing systems optimizations for debugging provenance queries. Lastly, we devise a new symbolic-execution based white-box testing algorithm for big data applications that abstracts the implementation of dataflow operators using logical specifications instead of modeling their implementations and combines them with the semantics of any arbitrary user-defined function. We instantiate the idea of an interactive debugging algorithm as BigDebug, the idea of an automated debugging algorithm as BigSift, and the idea of symbolic execution-based testing as BigTest. Our investigation shows that the interactive debugging primitives can scale to terabytes---our record-level tracing incurs less than 25% overhead on average and provides up to 100% time saving compared to the baseline replay debugger. Second, we observe that by combining data provenance with delta debugging, we can identify the minimum faulty input in just under 30% of the original job execution time. Lastly, we verify that by abstracting dataflow operators using logical specifications, we can efficiently generate the most concise test data suitable for local testing while revealing twice as many faults as prior approaches. Our investigations collectively demonstrate that developer productivity can be significantly improved through effective and scalable testing and debugging techniques for big data analytics, without impacting the DISC framework's performance. This dissertation affirms the feasibility of automated debugging and testing techniques for big data analytics---techniques that were previously considered infeasible for large-scale data processing

Querypoint Debugging

To fix a bug, software developers have to examine the bug-gy execution to locate defects. They employ different ap-proaches (e.g., setting breakpoints, inserting printing statements in the code) to navigate over buggy execution and inspect program state at suspicious points. In this pa-per we describe Querypoints, a new kind of compound conditional breakpoint relating two execution points. De-velopers specify Querypoints relative to a successfully paused conventional breakpoint or conventional watchpoint or to another Querypoint. The relative conditions contain runtime data values, like the last time a value was changed, or program statements, like the last conditional branch. The Querypoint combines the program state information from two execution points in the same execution; Querypoints can be chained to work backwards from effects to causes in a program. We present basic Querypoint concepts, two sample Que-rypoints, lastChange and lastCondition, and a description of our implementation of these Querypoints. To demon-strate that Querypoints are feasible we describe a prototype that implements an alternative approach to finding a bug in a graphical program analyzed previously with Whyline, one of the new logging-based debuggers

A Pointcut Language for Setting Advanced Breakpoints

In interactive debugging, it is an essential task to set breakpoints specifying where a program should be suspended at runtime to allow interaction. A debugging session may use multiple logically related breakpoints so that the sequence of their (de)activations leads to the expected suspension with the least irrelevant suspensions. A (de)activation is sometimes decided by some runtime context values related to that breakpoint. However, existing breakpoints, which are mainly based on line locations, are not expressive enough to describe the logic and the collaboration. Programmers have to manually perform some repeated tasks, thus debugging efficiency is decreased. In this paper, we identify five frequently encountered debugging scenarios that require to use multiple breakpoints. For such scenarios, it is often easier than using the traditional debugger to write pointcuts in an aspect-oriented language, and to suspend the execution at the selected join points. However, existing languages cannot handle the scenarios neatly and uniformly. Therefore, we design and implement a breakpoint language that uses pointcuts to select suspension times in the program. Our language allows programmers to use comprehensible source-level abstractions to define breakpoints. Also, multiple breakpoints can be freely composed to express their collaboration. In this way, an expected suspension can be expressively programmed and reached with less or even no irrelevant suspensions

Performance Debugging and Tuning using an Instruction-Set Simulator

Instruction-set simulators allow programmers a detailed level of insight into, and control over, the execution of a program, including parallel programs and operating systems. In principle, instruction set simulation can model any target computer and gather any statistic. Furthermore, such simulators are usually portable, independent of compiler tools, and deterministic-allowing bugs to be recreated or measurements repeated. Though often viewed as being too slow for use as a general programming tool, in the last several years their performance has improved considerably. We describe SIMICS, an instruction set simulator of SPARC-based multiprocessors developed at SICS, in its rôle as a general programming tool. We discuss some of the benefits of using a tool such as SIMICS to support various tasks in software engineering, including debugging, testing, analysis, and performance tuning. We present in some detail two test cases, where we've used SimICS to support analysis and performance tuning of two applications, Penny and EQNTOTT. This work resulted in improved parallelism in, and understanding of, Penny, as well as a performance improvement for EQNTOTT of over a magnitude. We also present some early work on analyzing SPARC/Linux, demonstrating the ability of tools like SimICS to analyze operating systems

Debugging by lastChange

Developers often seek the origins of wrong values they see in their debugger. Their search must be backwards in time: the code causing the wrong value executed before the wrong value appeared. Searching with breakpoint- or log- based debuggers demands persistence and significant experience with the application being debugged. We introduce a new, practical feature for debuggers called \textit{lastChange}, which automatically locates the last point that a variable or an object property has been changed. Starting from a program halted on a breakpoint, the \textit{lastChange} solution applies queries to the live program during re-execution, recording the call stack and limited program state each time the property value changes. When the program halts again on the breakpoint, the recorded information can be shown to the developer. As a proof of this concept, we developed \textit{Querypoint}, a prototype which enhances the popular Firebug JavaScript debugger with the \textit{lastChange} feature and studied users applying the prototype to some test cases. The approach used in implementing \textit{lastChange} combines the flexibility of breakpoint debugging with the expressive power of log-based query debugging. Contrary to other replay-based approaches, which require exactly the same re-executions (deterministic executions), our new approach only requires \textit{bug reproducibility}, meaning a test case is available which reproduces the bug and a way to halt execution reliably after the reproduction