Visual Debugging and Automatic Animation of C Programs 1

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 dierences 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 dierent 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 dierent 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 dierent 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 dierent 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 hookpoints must be included manually. The learning eort 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 Figure 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 code

Generator 1

Source with index of line numbers

C Preprocessor

Source without directives

Description of Structures Animation Library

Binary code

Linker (GNU C++)

and Functions

Generator 2

Source with

Object

ANSI C

code

Compiler

calls to graphical routines

Figure 2: Encapsulation Process.

4 System Architecture and Capabilities The system has two dierent 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 dierent 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: [email protected].

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 COMPUGRAPHICS'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. AddisonWesley, 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 Clis, 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