A Run-Time Type-Checking Debugger for C

Transcription

1 A Run-Time Type-Checking Debugger for C Alexey Loginov, Suan Yong, Susan Horwitz, and Thomas Reps University of Wisconsin 1 Introduction This document outlines progress to date on the run-time type-checking project funded in part by IBM. The project has been carried out during the last year by Alexey Loginov and Suan Yong, under the supervision of Professors Susan Horwitz and Thomas Reps. The goal of the project is the design and implementation of a debugging tool based on dynamic type checking. The major accomplishment during the last year has been an implementation of the tool for the (complete) ANSI C language. The tool instruments a program to monitor the type stored in each memory location (which may differ from the static type of that location due to the use of unions, pointers, and casting). Whenever a value is written into a location, the location s run-time type tag is updated to match the type of the value. Also, the location s static type is compared with the value s type; if there is a mismatch, a warning message is issued. Whenever the value in a location is used, its run-time type tag is checked, and if the type is inappropriate in the context in which the value is being used, an error message is issued. In preliminary tests, the tool has been used to find bugs in several Solaris utilities. The information provided by the tool is usually succinct and precise in showing the error location. The following activities (discussed in more detail below) are planned for the coming year: We will perform a more thorough testing study using larger input programs to validate the utility of our approach. We will study ways to lower the overhead of instrumentation. We will begin work on extending our tool to provide help in tracking down the original source of an error. 2 Motivation To help in the often frustrating task of debugging programs written in a language like C, we are developing a debugging tool that enforces type consistency at run-time. The tool essentially ensures that an executing C program complies with C s type system, which cannot be fully enforced statically. Features and functionalities like unions, casting of pointers, and pointer manipulation put the responsibility of ensuring type consistency in the hands of the programmer. While the programmer is given the flexibility to ignore types, our hypothesis is that a violation of type consistency is a likely indicator of a programming bug. Other run-time debugging tools, like Purify[4] and Safe Pointers[2], have been proposed, developed, and found to be useful. Our tool, however, can catch subtler bugs that cannot be detected by these tools. Generally, when data of one type is used as a different type, our tool will report an error. If this bug does not violate the spatial constraints of the C semantics (i.e., it does not access a memory location that, according to the C language specification, is undefined ), it will not be detected by the other tools mentioned. Such a situation can arise in programs that perform user-level memory management, simulate object-oriented inheritance with C structures, or simply use unions. 1

2 Consider the following example, which simulates object-oriented inheritance in C: 1: typedef enum { shape, polygon, circle } Type; 2: typedef struct { Type type; int color; } Shape; 3: typedef struct { Type type; int color; int sides; } Polygon; 4: typedef struct { Type type; int color; float radius; } Circle; 5:... 6: Shape * s = inputshape(); 7: switch(s->type){ 8: case polygon: printf(" %d sides\n", ((Polygon *)s)->sides);... 9: case circle: printf("radius = %f\n", ((Circle *)s)->radius); } Here Polygon and Circle are (conceptually) subtypes of Shape, with the two fields type and color common to all three structs. The purpose of the type field is to identify the (dynamic) type of the object, but it is the responsibility of the programmer to ensure that this field is set correctly. If s points to an object of type Circle whose type field is erroneously set to polygon, line 8 would attempt to use its third field, which actually contains a float (its radius), as if it were an int. This type inconsistency would be detected by our tool (but not by either Purify or Safe Pointers). This programming style is common, for example, in networking code, where message headers for different kinds of packet formats are handled in a manner similar to the above example[7]. 3 Implementation Our debugging tool comprises two major components: a compiler front-end that instruments the program, and a run-time system that tracks the dynamic type associated with each memory location. The run-time component is currently implemented by storing type information in a mirror of the memory used by the program. The mirror is allocated in 4K segments as user memory is touched. For a given byte of memory, its associated tag in the mirror is four bits in size, and encodes the type of the data in that memory location. Of these four bits, one is used to encode the extent (0 denotes the start of a new object, 1 denotes a continuation tag) and three are used to encode the six types that we currently track: unallocated, uninitialized, integer, real, pointer, and bit-fields. Different pointer types are not distinguished, since C s casting in a sense makes any pointer a generic pointer. Aggregate objects are broken down into their scalar components, whose types are tracked individually. The interface to the run-time system consists primarily of functions that set and update a tag, retrieve a tag, and verify that a tag agrees with an expected type. We also have a function (verifyptr) to verify that a pointer points to allocated memory before it is dereferenced, and a set of functions to handle the passing of function parameters and return values (their tags are passed in an array via a global pointer). Because these run-time operations are implemented in functions that are written with flexibility in mind, the run-time overhead of our instrumentation is currently exorbitant (up to 100x slowdown). Reducing this overhead (e.g., by converting functions to macros and by using static analysis to identify which instrumentation code can be safely omitted) is a subject of future work, described below in Section 5. To instrument a program, we perform a source-to-source transformation on the C source files using Ckit[3], a C front end written in ML. Working at the source level gives us access to all the source-level type information we need. Also, the flexibility of the comma operator in C makes it possible to preserve the ANSI C semantics of the original program while retaining portability: an instrumented C file can be compiled on multiple platforms. 1 1 Note: the Ckit front end does not currently support C-preprocessor directives, so at present we can only instrument preprocessed C code. This limits portability to some extent, but is not a fundamental limitation of our approach. 2

3 To illustrate the syntax-directed transformations that we perform to instrument C expressions, consider instrumenting the expression x = *p. The instrumentation function, instr, takes as arguments the expression to be instrumented, a boolean (enforce) that specifies whether the expression s run-time type must match its static type, and a (temporary) variable to be set to point to the expression s tag. The rule for instrumenting an id expression is (roughly) as follows: 2 exp instr(exp,enforce,tmp tagptr ) *(tmp tagptr = gettagptr(&id), id verifytag(tmp tagptr, typeof(id)), &id) // omit if tmp tagptr = null // omit if enforce = false The instrumented expression is shown in the right-hand column. First, (if tmp tagptr is not null) tmp tagptr is set to point to the tag of id (obtained using the function gettagptr from our run-time library). Next (if enforce = true) the verifytag function is used to verify that the tag associated with id agrees with its declared type. Overall, the instrumented code has the form *(..., &id); this is so that the instrumented expression is both a valid rvalue and a valid lvalue. The tmp variables are temporaries (of appropriate type), each used only within the scope of an expression. The rules for dereference and assignment are as follows: exp instr(exp,tmp tagptr ) *(tmp e = instr(e, true, null), verifyptr(tmp e, sizeof( e)), e tmp tagptr = gettagptr(tmp e ), verifytag(tmp tagptr, typeof( e)), tmp e ) // omit if tmp tagptr = null // omit if enforce = false (tmp assign = instr(e 1, false, tmp tagptr ) = instr(e 2, true, tmp tagptr2 ), e 1 = e 2 copytag(tmp tagptr, tmp tagptr2, sizeof(e 1 )), tmp assign ) For the dereference case, the subexpression e is first instrumented with enforce = true (since e will be dereferenced, i.e., used ). Next, verifyptr verifies that e does not point to unallocated memory. After that, we set the tag pointer and verify the type, just as in the id case. In the assignment case, we instrument e 1 with enforce = false, since we do not care about the type of the data that is about to be overwritten. The copytag function copies the tag of the right-hand-side expression to the left-hand-side expression, and also issues a warning message if the type of the right-hand-side expression is not compatible with the static type of the left-hand-side expression. Since an assignment cannot be an lvalue, it is not necessary for the instrumented code to have the form *(..., & ). We must, however, still make sure that the instrumented expression is a valid rvalue, which is what tmp assign is for. Using these rules, the expression x = *p, where x is of type int, would be instrumented as follows: (tmp1 = *(tmp2 = gettagptr(&x), &x) = ( tmp4 = ( tmp5 = gettagptr(p), verifytag(tmp5, pointer_type), p), verifyptr(tmp4, sizeof (*e)), tmp3 = gettagptr(tmp4), verifytag(tmp3, int_type), *tmp4), copytag(tmp2, tmp3, sizeof(x)), tmp1) 2 We omit some details that would simply complicate the example. For instance, we actually have two separate functions to instrument lvalues and rvalues. 3

4 Handling the entire C language was non-trivial since a number of C s features make correct instrumentation difficult. The following summary of the instrumentation that the tool performs hints at some of the issues: 1. Each program statement is instrumented using a set of syntax-directed transformations. Code for updating, retrieving, or verifying tags is added to each expression, with the aid of the comma operator (as illustrated in the example given above). 2. For a function call, code is added to store the tags for the actual parameters in an array, whose address is stored in a global pointer. The same pointer is used to extract the tag for the return value. 3. At the head of a function definition, code is added to extract the tags of the parameters passed to the function. At a return statement, the mirror for the entire stack frame of the function is cleared to unallocated, and the tag of the return value is assigned to the global pointer (to be extracted by the caller). 4. Every instance of main is renamed to prog main. Our run-time system defines its own main function, which performs some initialization before calling prog main. This way, we can process command-line arguments for the run-time system, and recursive calls to prog main do not cause any problems. 5. Tags for global and static variables are initialized in a special init function; one such function is created per source file. Our main function calls each of these init functions before calling prog main (these init functions from the different source files are collected at link time). 6. Local variables are tagged uninitialized. A local variable that is initialized is processed as if the initialization expression were assigned to that variable. Because our instrumentation code needs to take the address of all variables, register variables are demoted to regular auto variables. 7. We treat extern variables that are not defined in any of the instrumented source files specially. To allow our instrumented source file to be linked with uninstrumented object code (most commonly library modules), we assume extern variables to be wellbehaved, and so initialize their tags to contain their declared types. A final component necessary for proper type checking is for us to handle malloc functions specially. We replace each call to malloc (and related functions) with its own version which, upon successfully allocating a block of memory, initializes the mirror for that memory block with the uninitialized tag. Similarly, our free function resets the mirror to be of unallocated type. As hinted at by item 7 above, the approach we have taken allows us to link instrumented modules with uninstrumented ones. Our only requirement is that the program s main function must be renamed to prog main. This flexibility is useful if, for example, a programmer only wants to debug one small component of a huge program: they can instrument just the files of interest, and link them in with the other uninstrumented object modules. A caveat when doing this, however, is that type information for the uninstrumented parts of the program is not maintained. In particular, if a reference to a valid object in the uninstrumented portion of the program is passed to an instrumented function, it will think that the object is unallocated, and may output spurious warnings. This problem extends, in general, to library modules. For example, the flow of values in a function like strcpy, and the initialization of values from input in a function like fgets are not currently captured. For library functions that affect type flow, we are in the process of building up a collection of instrumented versions. These are wrappers of the original functions, hand-written to capture their type behavior. 4

5 4 Initial Experiments To test the effectiveness of our debugging tool, we used Fuzz[6] to find Solaris utilities that crash on some inputs, and instrumented five such programs for testing (nroff, plot, ul, units, col). A summary of what our tool revealed about each of the crashing runs is given below. nroff: An array of pointers is accessed with a negative index, and the retrieved word, when dereferenced, causes a segmentation fault. The instrumented program, before crashing, warns that the retrieved word that is about to be dereferenced actually contains an array of characters. plot: A rogue pointer, after passing beyond the bounds of an array, walks up the stack, writing bytes as it goes. It eventually goes past the end of the memory segment, at which point the program crashes. The instrumented program outputs a long list of warnings signaling these writes to unallocated memory, accurately identifying the line of code where this occurs. ul: The original program crashes during a call to fgetwc, while the instrumented program crashes during a call to fprintf as our instrumentation code is attempting to write a warning message. The cause of the crash in the original program was difficult to track down, but dereference to unallocated memory warnings generated by our instrumented program led us to the cause of the crashes: a pointer, after passing beyond the bounds of an array, walks through the bss section and eventually writes to the global iob array (which contains stdin, stdout, and stderr), hence causing the subsequent call to a stdio function to crash. units: In the original program, an errant pointer manages to corrupt the save area of the call stack, resulting in bizarre behavior that was difficult to track down. The instrumented program detects a type-violation error after the character pointer cp is set to point to itself, and is subsequently used to write a character value onto itself. The next dereference of cp generates another error, and then the program crashes. col: The original program crashes on a dereference of a bad pointer, but our instrumented program does not crash; instead, it fails to terminate (at least, after two hours we stopped waiting for it to terminate). The first of many error messages generated by our instrumented program signals a dereference into unallocated memory, and points to the line in the program where the crash occurs (in the uninstrumented code). The point where the error was generated is probably close to where the pointer first stepped out of bounds of the global array to which it pointed. In all cases, the crashes in the test inputs were found to have been caused by a pointer (or array index) that had gone astray. In each case, our tool was able to detect the outof-bounds memory accesses when the type of the pointed-to memory was different from the expected type. While these results are very encouraging, these kinds of errors would also be detected by Purify. We can easily create examples (such as the one given in Section 2) for which our tool is able to detect errors that are not detected by Purify; however, we have not yet found examples of those kinds of bugs in real programs. We suspect that such bugs are more likely to occur in large, complicated programs, but due to limitations of the current version of the Ckit front end (enhancements are pending), we have not been able to successfully compile many large programs. Furthermore, the code that we have used to date for testing our technique is in most cases robust code that has been in use for quite some time. As a result, the likelihood of finding errors is lower than if the tool were applied to code during the software-development cycle. We plan to change our testing strategy to reflect this, as discussed in the next section. 5

6 5 Future Work Our future plans include performing a more thorough testing study, lowering the instrumentation overhead, and developing techniques to help programmers find the original sources of errors that manifest themselves as bad run-time types. Our immediate goal is to search for more buggy source code to gauge the utility of our approach. One potential testing avenue could be an industrial code base complete with revision information and bug logs. The ability of our tool to retrace the error-detection cycle (and possibly find previously undiscovered errors) would be a way of demonstrating the utility of our tool. A second goal is to speed up the execution of instrumented programs. Improvements can be made at two levels. First, our tool was built with a great deal of flexibility in mind. Recently, we have made some decisions that should allow us to dramatically simplify the instrumented code by removing some of the features that we have decided are no longer necessary. In addition, we believe that a significant proportion of the instrumentation code can be statically determined to be unnecessary, and thus be removed. For example, if the value in a location is used multiple times, and there is no possibility that its type is modified between the uses, then only the first use needs to be checked. A fairly standard analysis can be used to identify which locations might be modified and which locations might be used by each expression in the program (with the caveat that any write via a pointer must be treated with special care, since a corrupted pointer can point to an arbitrary location). Once that has been done, it is straightforward to find definition-free paths between uses. We will work on identifying other conditions under which variables need not undergo dynamic type checking, and will formulate appropriate dataflow problems to identify them. Since our technique is of use primarily in programs that make use of pointers and heap-allocated storage, pointer analysis is a prerequisite for this work. We plan to build on our previous results on flow-insensitive points-to analysis[9]; in particular, we will use the pointer-analysis tool implemented as part of that work in this project s static-analysis phase. As discussed above, instrumented code currently issues a warning message when a value of one type is assigned to a location of a different type. It may be useful to add an option so that in such cases control is passed to an interactive debugger like GDB[8] (e.g., by sending a signal that is caught by GDB). This would permit the programmer to use the interactive functionalities of GDB to examine the program state to understand the cause of the type inconsistency warning, and whether it indicates a logical error. The programmer may also want the ability to examine and update type tags (to stop false warnings, for example). We will investigate providing an easy-to-use interface to permit such actions. A much more ambitious goal is to add features to our tool to help programmers identify the errors in their code that (eventually) manifest themselves as bad uses of run-time types. We illustrate this idea by expanding on the example from Section 2 (we assume the same typedef declarations as in that example). 1: Shape s;... 2: float a = area(&s);... 3: float area(circle * c) { 4: float r = c->radius; 5: return PI * r * r; 6: } In this code, the address of s, which is a Shape, is erroneously passed as the argument to function area, which expects a pointer to a circle. (When compiled with gcc, this causes a warning but not an error. Some programmers write code that produces many such warnings, which are ignored.) Note that there are three points of interest in this code: 6

7 1. Line 2 is the real source of the error. This is the point where an argument of the wrong type is passed to function area. 2. On line 4, an incorrect type is written into r, because c->radius accesses a location past the end of the structure. (Our tool would cause a warning message to be issued at this point. Purify would not detect this error since the structure pointed to by c is on the stack.) 3. On line 5, variable r is used in the computation of the return value. However, the value of r has the wrong type (and therefore an error message would be issued by our tool, but not by Purify). The goal of this part of our proposed future work is to develop a methodology for guiding the user to the original source of the error, in this case line 2. (It is worth noting that techniques developed to address this problem would not be limited in applicability to our tool; other debuggers could benefit from the same ideas.) Both static and dynamic program slicing [10, 5, 1] are relevant, and we will investigate their utility in this context. Another possibility is to provide a way for the user to roll back the program state (including the type state) to an earlier point in order to find the source of a problem. This is similar to reverse execution in debuggers and requires a checkpointing scheme. We may be able to build on work currently being done by Glenn Ammons, another graduate student at the University of Wisconsin. As described in Section 4, the behaviors of the test programs ul and col were modified by our instrumentation (Purify also significantly changes those programs behaviors). A potential improvement to the tool would be to reduce or eliminate such interference. These behavioral changes are partly due to the addition of local temporary variables, which are necessary for the instrumented code to preserve the language-level semantics of the original program. Since these temporary variables are currently allocated on the stack, they alter the layout of local variables in a function s activation record. While correct and portable programs do not make any assumptions about the layout of a function s activation record, these changes do affect the behavior of many buggy programs. As a result, the behavior of the original program and that of the instrumented one sometimes differs, even though the cause of the errors is the same. In this case, moving the temporary data to the heap and making use of page-protection tricks can allow us to lower the interference of our instrumentation, as well as to protect the type-state data from buggy code. There are also a few miscellaneous enhancements that can improve error precision. For example, we can obtain more complete information about program behavior by making sure that all memory-allocation operations are visible to our tool. (Presently, this is only the case for memory that is allocated in code that we instrument.) In addition to helping us detect errors in libraries for which we do not have source code, this will allow us to do a better job of selective instrumentation. One key to the tool s success will be the ability to safely focus on code likely to contain errors without having to instrument the complete system. This will greatly improve performance and the ease of use of the tool. To summarize, the short-term emphasis will be on performing more thorough testing and some of the more straightforward hand-optimizations. The basic performance improvements will help us streamline the validation tests. Which of the longer-term goals described above will be addressed subsequently will depend, in part, on the results of those tests. References [1] H. Agrawal, J. Horgan. Dynamic program slicing. In Proceedings of the ACM SIGPLAN 90 Conference on Programming Language Design and Implementation (1990), pp SIG- PLAN Notices 25(6). [2] T. Austin, S. Breach, G. Sohi. Efficient Detection of All Pointer and Array Access Errors. SIGPLAN 94 Conference on Programming Language Design and Implementation,

8 [3] Ckit. [4] R. Hasting, B. Joyce. Purify: Fast Detection of Memory Leaks and Access Errors. Proceedings of the Winter Usenix Conference, [5] B. Korel, J. Laski. Dynamic program slicing. Information Processing Letters 29, 3 (1988), pp [6] B. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, J. Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. University of Wisconsin- Madison, ftp://grilled.cs.wisc.edu/technical papers/fuzz-revisited.ps [7] M. Siff, S. Chandra, T. Ball, K. Kunchithapadam, T. Reps. Coping with type casts in C. In Proceedings of ESEC/FSE 99: Seventh European Software Engineering Conference and Seventh ACM SIGSOFT Symposium on the Foundations of Software Engineering (Toulouse, France, Sept. 6-10, 1999), pp [8] R. Stallman, R. Pesch. Using GDB: A Guide to the GNU Source-Level Debugger. July [9] S. Yong, S. Horwitz, T. Reps. Pointer Analysis for Programs with Structures and Casting. In Proceedings of the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation (Atlanta GA, May 1-4, 1999), pp [10] M. Weiser. Program slicing. IEEE Transactions on Software Engineering 10, 4 (1984), pp