Visualizing Memory Graphs

Abstract

Abstract.To understand the dynamics of a running program, it is often useful to examine its state at specific moments during its execution. We present memory graphs as a means to capture and explore program states. A memory graph gives a comprehensive view of all data structures of a program; data items are related by operations like dereferencing, indexing or member access. Although memory graphs are typically too large to be visualized as a whole, one can easily focus on specific aspects using well-known graph operations. For instance, a greatest common subgraph visualizes commonalities and differences between program states. Keywords: program understanding, debugging aids, diagnostics, data types and structures, graphs A Structured View of MemoryExploring the state of a program, to view its variables, values, and current execution position, is a typical task in debugging programs. Today's interactive debuggers allow accessing the values of arbitrary variables and printing their values. Typically, values are shown as texts. Here's an example output from the GNU debugger GDB:(gdb) print *tree *tree = {value = 7, name = 0x8049e88 "Ada", left = 0x804d7d8, right = 0x0, left thread = false, right thread = false, date = {day of week = Thu, day = 1, month = 1, year = 1970, vptr. = 0x8049f78 Date virtual table }, static shared = 4711} (gdb) _ Fig. 1. Printing textual data with GDB Although modern debuggers offer graphical user interfaces instead of GDB's command line, data values are still shown as text. This is useful in the most cases, but fails badly as soon as references and pointers come into play. Consider Figure 1, for example: where does tree-> left point to? Of course, one can simply print the dereferenced value. However, a user will never notice if two pointers point to the same address-except by thoroughly checking and comparing pointer values.

Prioritization of Functional Test Suites Using Closed Dependency Structures

“…Zeller, et al [11] propose a program statebased debugging approach, delta debugging [13] to reduce the causes of failures to a small set of variables by contrasting program states between executions of a successful test and a failed test via their memory graphs [12]. Variables are tested for suspiciousness by replacing their values from a successful test with their corresponding values from the same point in a failed test and repeating the program execution.…”

Discriminative pattern mining in software fault detection

“…The original Delta debugging technique implements the "search in space" concept by comparing memory graphs [19] of failing and passing test runs, thus narrowing down the difference between these runs to a set of suspicious variables. In addition to "search in space" the Cause Transition Algorithm performs "search in time" by exploiting cause transitions [4].…”

When Abstraction Fails

“…Yet, the technique has been shown to produce useful diagnoses for programs as large as the GNU compiler (GCC). As detailed in [2], scaling up the general idea, as sketched here, requires capturing and comparing program states as memory graphs [4]. Also, Delta Debugging must do more than simple binary search; it needs to cope with interferences of multiple failure-inducing elements as well as with unresolved test outcomes [3].…”