Visual Debugging and Automatic Animation of C Programs

R.A. Baeza-Yates, G. Quezada, G. Valmadre

Depto. de Ciencias de la Computacion
Universidad de Chile
Blanco Encalada 2120, Santiago, Chile

Abstract
We present VCC, a system that allows the end-user to graphically visualize and animate a C program.
We emphasize the di erences between our approach and previous works on the topic. This system can
be seen as a preprocessor that automatically annotates a C program with animation code, and embeds it
in a special graphical environment. The system is implemented in C++ and C, and uses the X-Windows
environment, making it highly portable. It can be used for several purposes, including debugging,
teaching, understanding, and exploring algorithms and static data structures.

1 Introduction
Visualization of a dynamic process facilitates its understanding, and has a bearing on research and teaching.
In particular, allows to understand a program in execution. Although there are some systems that perform
this task, we have taken a somewhat di erent approach. We have used the best features of known systems
and combined them with some new ideas to produce VCC (Visual C). This chapter gives an overview of
VCC, and compares it to other program animation tools. The rst results of this project were presented in
[1, 2], while here we describe our second and nal prototype.
Program visualization has been used in many di erent contexts. Among them we can mention teaching
[3, 4], debugging [5, 6, 7], concurrent programming [5], algorithm design [8, 9], software development [10],
and performance evaluation [11, 5].
The main characteristics of VCC are:
 Given an ANSI C program, VCC automatically introduces animation code into the program, embedding
it in a graphical environment.
 The user-interface is built on top of X-Windows and provides several windows for di erent views of
the program, including the code itself, the current active function, the tree of function calls, and the
data structures with their values.
 For visualizing data, a xed set of possible views are provided, including a debugging mode and a small
number of visual modes, depending on the data type.
The main new features of VCC are that an end-user does not need to know any detail about how to
animate a C program, and the animation environment is fully interactive. This allows the system to be used
for teaching, where a student can debug, understand, and explore a program without any special knowledge.
On the other hand, the visualization will not be as close to the program semantic as in other systems, and
the animation may not re ect some aspects of it. At this point is necessary to clarify that VCC just analyzes
the semantics of simple program instructions rather than composed statements. In fact, VCC does not try

1
to understand what the program does as other tools [12, 13]. It only analyzes every data action, and follows
a set of simple rules to generate the graphical code. A program is compiled by just using vcc program.c,
then run the executable le.
The organization of the rest of the chapter is as follows: the next section describes related work; we
then give an overview of VCC and its user interface; followed by the system main design characteristics.
Finally, we overview the di erent functionalities of the system, and the last section discusses current and
future development.

2 Related Work
Several program visualization tools have been developed in the past. All of them attach hook-points to
the program. These hook-points can be code intrusive (CI) or data intrusive (DI) [14], and are generated
manually (M) or automatically (A). Code intrusive hook-points are special function calls inserted in the
original program code. Data intrusive hook-points are used in object oriented languages by subclassing
existing object classes and providing new methods which will drive the animation. We use the above
concepts to classify several systems. For example, VCC is a CI-A system. A more complete taxonomy for
these systems can be found in [15], and also gives more information on the systems described below. Other
systems are also described and compared in [16, 17, 18, 19].
Perhaps the best known system is BALSA (from Brown University) [20, 21], and its successor BALSA-II
[19, 8]. Although BALSA is incredibly powerful, it is not trivial to de ne a new visualization, and the hook-
points must be included manually. The learning e ort for either system is initially higher than for other
systems [8]. In fact, BALSA-II is a CI-M type system. BALSA has been used extensively, with a high level of
success, for teaching algorithms in a laboratory where the students can see a visualization developed by the
instructor [22]. The latest descendent of BALSA is Zeus, which also introduces sound into the animations
[23, 24].
Another interesting system was developed at Tektronix for Smalltalk programs [25, 26, 27]. One of its
advantages is that the animation code is embedded in the data by using subclasses of the program classes.
Thus, this is a DI-M system. The main drawbacks are that updating multiple views is done in a sequential
way, which does not allow composite views. Furthermore, some types of interactions are not possible due
to the asynchrony of the animation of each object. Our system does not have this problem, inherent in an
object oriented animation.
Incense [7] is another system which permits visualization of data structures interactively. Its main goals
are debugging, tracing and program documentation. Tango [18] is a recent system similar to BALSA which
is based in a special temporal framework. This system requires manual annotation, and a new visualization
can be designed in, at most, a few days.
The University of Washington Illustrating Compiler (UWPI) [28] is the closest to the system presented
here. UWPI is another CI-A system, and supports a subset of Pascal that is similar to RATFOR. It does
not support types, records, or pointers. Also, UWPI is not an interactive system.

3 System Overview
The main goals behind the use of VCC, as in similar systems, are:
 Understanding: the user comprehends faster what the program does. Thus, it is easier to teach data
structures and algorithms, either in a special lab or by personal assignments. Another related goal is
an animated and computerized version of a set of standard algorithms[29].
 Debugging: \one picture is worth a thousand words". By looking at a bug visually it is easier to see
where and why it happened. For example, one can readily nd a null pointer or recognize that an array

2
 index is out of range. In a traditional Unix environment these kind of run time errors give awkward
messages such as \segmentation violation", \bus error", etc.
 Visualizing Performance: visual animation of an algorithm allows to gain insight into how it performs.
This encourages improvements in known algorithms or nd new ideas.

Figure 1: Second prototype.

The VCC user interface tries to ful ll the above goals. Figure 1 shows the user interface of our second
prototype, which is a snapshot of the execution of a typical implementation of Quicksort taken from [29].
The system includes the following views of the program, each of them in a window:
1. Current activated function, showing its name, arguments, and local variables (right side of Fig-
ure 1).
2. Current tree of program calls. The current activated sequence of nodes is given by a solid line
that starts at the root (middle of Figure 1). The arguments given to each called function and its

3
 local variables can be obtained by pointing to the associated node. So, we have the full history of
subprogram activations.
3. Program code. One window has the code of the program, where the current line is highlighted (left
of Figure 1).
4. Standard I/O. This window replaces the standard I/O of the program (right top corner of Figure 1).
5. Data views. Complex data structures, such as records and arrays, are shown, each in a separate
window. Their functionality depends on the data type (to be explained later).
All windows support scrolling, resizing, and other typical window operations; and the user decides which of
them are open. We later detail additional features of these windows, in particular that some of them have
several visualization choices for the same element.
The control panel (left top corner of Figure 1) allows the user to: run, stop, restart, or quit the animation;
set a continuous or discrete (trace) animation of the program (every discrete step is de ned as a visual event);
change the speed of the animation; de ne breakpoints and to load or save customized event con gurations,
including color and sound mappings.

Original Source with Source without

source index of C
Generator 1 Preprocessor directives
code line numbers

Description
of Structures
and Functions
Animation Generator 2
Library

Source with
Binary Object ANSI C calls to
code Linker
code graphical
(GNU C++) Compiler
routines

Figure 2: Encapsulation Process.

4 System Architecture and Capabilities

The system has two di erent components: the generator of animation code and the graphical library. The
generator has two components. The rst pass gathers information about all the data structures and functions
used in the program. The second pass is run between the standard C preprocessor and the C compiler. The
annotated program is compiled and linked with the special animation library. Only the library is dependent
of the windowing system, which is X-Windows [30]. The complete process is shown in Figure 2.
The current version of the code generator assumes \structured programming". For example, it does not
support a goto from outside to inside a loop. Because static binding does not follow all possible variable

4
references in a program, the preprocessor creates a dynamic table where the variable addresses are stored.
This includes the struct and union constructs. This table is used at run time to bind a variable reference
to the graphical event associated. The generator supports the full ANSI C language, although the quality
of the generated code is proportional to the clarity of the original code. The generator is built using the
standard tools for compilers available in Unix (Lex and Yacc), and is written in C.
The basic events detected by the generator are:
 assigning local variables including record elds or memory cells,
 instructions involving comparisons with at least one array element,
 function calls/exits and their arguments/return values,
 standard input/output through the printf and scanf functions, and
 allocating/freeing dynamic memory through the standard allocation routines (malloc and free).
Values of the local variables can be seen at run-time. However, management of global variables is not
supported.
The second component is the graphical library, which is the interface between the animation code and the
windowing system. The library is implemented using Xlib [30] and the Xt toolkit [31], and is written mostly
in C++. Every program component is an instance of a certain class, and those are instances of generic
metaclasses (for example, a C function is a metaclass, a speci c function is a class, and every call to that
function is an instance of that class). Because metaclasses are not supported by C++, we have implemented
them. Some of the capabilities of this library are detailed in the following sections.

Figure 3: Program outlined with lines.

5 Functionality
We can divide the basic functionality in three aspects: program debugging, data visualization and visual
customization. In the following sections we explore them using the views already de ned.

5
5.1 Program Debugging
We already mentioned that the code and the tree of program calls can be visualized. Another view of the
code which is represented as lines (following [32]) is available. In this manner, a larger piece of code can be
seen at once and many times the outline of the code is enough to know where we are. An example is shown
in Figure 3

Figure 4: Visual view for an array using bars.

In addition to a step by a step animation or a continuous animation with a user chosen delay, it is possible
to de ne breakpoints. Breakpoints are de ned either using function names or program lines associated to
the numbering given in the code view (which is the original program). They can be added or deleted at any
time.
As we already pointed out, the system automatically checks for array indices out of range and null
pointers. Whenever one of these exceptions occur, the event is graphically depicted and the user must decide
if the animation continues or not in spite of the error. If so, the original program line is then executed with
the risk of an execution error.
5.2 Data Visualization
In addition to the history mechanism associated to the tree of program calls, any variable can be visualized
at any time, seeing its content on the active function window. If the variable is a record or an array, we
obtain all its values in a new window by pointing at it. For arrays we have a debugging view and several
visual views. We discuss them in the following paragraphs.
In the debugging mode the user sees every detail of the data. An example is shown at the bottom of
Figure 1. An index out of range is shown to the left or to the right of the array, depending on its value. A
comparison is also highlighted when it occurs. If every element of the array is a record, the rst element of
it is shown. However, the user may change this at run time via a menu option. The other values can be
obtained by pointing at each array cell.
Once the program appears to be correct, we need a high level view of its behavior. This is provided by a
view that allows better understanding of the whole data set. An example is shown in Figure 4, which shows
the relative sizes of the elements and not their absolute values. We can clearly follow how the sorting is
done, and we can have a larger number of elements visible in the window. Another visual view is shown in
Figure 5.

6
 Figure 5: Another visual view for arrays.

5.3 Personalizing the Animation

We already pointed out that the user can choose which windows are open and which views should be used.
Moreover, the user can also select the events that should be animated and associate to each event a color
and a sound. This feature is called a lter. When the user is satis ed with the set of colors and sounds
selected, this selection can be saved. Later, a lter can be loaded for the same or a di erent animation. The
control panel used to de ne a lter is shown in Figure 6.

Figure 6: Control panel to associate color and sound to events.

6 Concluding Remarks
There are several extensions that are being included or are planned in our system. Simple extensions consider
to allow changing the value of any variable; to detect other typical bugs, like a division by zero; and to add
more views to the elements already visualized.
Further work on this system includes:
 drawing of dynamic structures such as linked lists, trees, and graphs;
 add views to trace the use of dynamic memory;

7
  use of sound to represent arithmetical operations;
 extension of the I/O manager to allow redirection; and
 recognizing further relevant events, for example other I/O or memory allocation operations.

Figure 7: Animation of a string searching algorithm.

The main issue of automatic animation systems is how much of the semantic of the program can be
captured. We believe that trying to automatically understand a program is not possible in such a way that
satis es every example. On the other hand, the program semantic can be added by the user at run-time. In
that sense, we are modifying VCC to allow the user to attach simple graphics, color, and sound to a sequence
of events, extending what we already have for basic events. Events will also be user de ned by the use of
breakpoints and conditions that must be satis ed by a given set of variables. All the user selections can be
saved and loaded in a subsequent execution.
There are problems where automatic code generation does not suce, because semantic understanding
is necessary. In particular, we are doing this for hard algorithmic problems, where visualization helps at the
research level. One of these, not treated by other systems, is text searching. For this case we have built
a special system, Xaa [33], which animates one and two dimensional text searching algorithms, allows to
edit and generate input sequences and to obtain statistics of the algorithm execution. Figure 7 shows the
animation of a string searching example and the associated statistics.

Acknowledgments
This work was supported by Grants Fondecyt 91-0868, 93-0765 and 95-0622 of CONICYT Chile. We
acknowledge the helpful comments of the referees which improved the presentation of this work. E-mail
contact: rbaeza@dcc.uchile.cl.

8
References
References
[1] R. Baeza-Yates. Another look at program visualization and algorithm animation. In XVII Latinamerican
Conference on Informatics, pages 409{418, Caracas, Venezuela, July 1991.
[2] R. Baeza-Yates, L. Jara, and G. Quezada. VCC: Automatic animation of C programs. In COMPU-
GRAPHICS'92, pages 389{397, Lisboa, Portugal, December 1992.
[3] Marc H. Brown, Norman Meyrowitz, and Andries Van Dam. Personal computer networks and graphical
animation: Rationale and practice for education. ACM SIGCSE Bulletin, 15(1):296{307, Feb 1983.
[4] J. Nievergelt, A. Ventura, and H. Hinterberger. Interactive Computer Programs for Education. Addison-
Wesley, Reading, Mass., 1986.
[5] T. Lehr, Z. Segall, D.F. Vrsalovic, E. Caplan, A.L. Chung, and C.E. Fineman. Visualizing performance
debugging. IEEE Computer, 22(10), 1989.
[6] S. Isoda, T. Shimomura, and Y. Ono. Vips: A visual debugger. IEEE Software, 4(2):8{19, May 1987.
[7] B.A. Myers. Incense: A system for displaying data structures. Computer Graphics, 17:76{93, Nov 1981.
[8] M.H. Brown. Exploring algorithms using Balsa-II. IEEE Computer, 21(5):14{36, May 1988.
[9] J. L. Bentley and B. W. Kernighan. A system for algorithm animation: Tutorial and user manual.
Technical Report 132, AT&T Bell Labs, Murray Hill, N.J., Jan 1987.
[10] G.P. Brown, R.T. Carling, C.F. Herot, D.A. Kramlich, and P. Souza. Program visualization: Graphical
support for software development. IEEE Computer, pages 27{35, Aug 1985.
[11] Berhard Plattner and Jurg Nievergelt. Monitoring program execution: A survey. IEEE Computer,
14:76{93, Nov. 1981.
[12] W.L. Johnson and E. Soloway. PROUST: Knowledge-based program understanding. IEEE Trans. on
Software Engineering, SE-11(3):267{275, March 1985.
[13] M. Eisenstadt, B.A. Price, and J. Domingue. Software visualization as a pedagogical tool: Redressing
some ITS fallacies. Technical report, Human Cognition Res. Lab., Open University, Milton Keynes,
UK, 1992.
[14] R. R. Henry, K.M. Whaley, and B. Forstall. The University of Washington illustrating compiler. In
Proc. ACM SIGPLAN'90, pages 223{233, White Plains, NY, June 1990.
[15] Blaine A. Price, Ronald M. Beacker, and Ian S. Small. A principled taxonomy of software visualization.
Journal of Visual Languages and Computing, 4:211{266, 1993.
[16] G-C. Roman and K. Cox. A taxonomy of program visualization systems. IEEE Computer, 26:11{24,
1993.
[17] B. Myers. Taxonomies of visual programming and program visualization. J. of Visual Languages and
Computing, 1(1):97{123, 1990.
[18] John T. Stasko. Tango: A framework and system for algorithm animation. IEEE Computer, 23(9):27{39,
Sep 1990.

9
[19] M. H. Brown. Algorithm Animation. MIT Press, 1988.
[20] M. Brown and R. Sedgewick. A system for algorithm animation. Computer Graphics, pages 177{186,
July 1984.
[21] M. H. Brown and R. Sedgewick. Techniques for algorithm animation. IEEE Software, pages 28{39, Jan
1985.
[22] Marc H. Brown and Robert Sedgewick. Progress report: Brown university instructional computing
laboratory. ACM SIGCSE Bulletin, 16(1):91{101, Feb 1984.
[23] M.H. Brown. Zeus: A system for algorithm animation and multi-view editing. In IEEE Workshop on
Visual Languages, October 1991.
[24] M.H. Brown and J. Hershberger. Color and sound in algorithm animation. In IEEE Workshop on
Visual Languages, October 1991. (video also available).
[25] R.A. London and R.A. Duisberg. Animating programs using Smalltalk. IEEE Computer, pages 61{71,
Aug 1985.
[26] R. A. Duisberg. Animated graphical interfaces using temporal constraints. In Proc. ACM SIGCHI 86
Conf. Human Factors in Computing Systems, pages 131 { 136, April 1986.
[27] R. A. Duisberg. Visual programming of program visualizations. In Proc. Conf. Visual Languages, Aug.
1987.
[28] K. Andrews, R.R. Henry, and W.K. Yamamoto. Design and implementation of the UW illustrated
compiler. In Proc. ACM SIGPLAN'88, pages 105{114, June 1988.
[29] G.H. Gonnet and R. Baeza-Yates. Handbook of Algorithms and Data Structures - In Pascal and C.
Addison-Wesley, Wokingham, UK, 1991. (second edition).
[30] Robert W. Schei er, James Gettys, and Ron Newman. X Window System. Digital Press, 1988.
[31] Douglas A. Young. X Window System Programming and Applications with Xt. Prentice Hall, Englewood
Cli s, NJ, 1989.
[32] Stephen Eick. Graphically displaying text. Journal of Computational and Graphical Statistics, 3(2):127{
142, 1994.
[33] R. Baeza-Yates and L. Fuentes. Xaa: A framework to animate text algorithms. In XIX Latinamerican
Conference on Informatics, pages 15{22, Buenos Aires, Argentina, Aug 1993.

10