Method and System for Dynamically Detecting Leaked Memory Space in a Computer Program

The present invention relates to a method and system for detecting leaked memory space in a computer program and, more particularly, to a method and system for detecting leaked memory space in a computer program by employing a hybrid memory searching and memory sweeping technique.

The dynamic management of memory space within a running computer program has long posed a challenge to programmers. As a general rule, wasted memory space must be avoided because computer memory ultimately remains a finite machine resource. A corollary to this rule requires that dynamic memory space that is temporarily allocated must be efficiently tracked and reclaimed.

One problem in dynamic memory management is the avoidance of "leaked" memory space. A memory leak is a block of dynamic memory which cannot be freed for use by the running program because the reference pointers to the memory block have been lost. Repeated generation of leaked memory space can cause a program to run out of memory or cease functioning altogether, perhaps with disastrous results.

Conventional approaches to detecting leaked memory space employ various forms of memory "sweeping" and are primarily limited to post-execution program analysis. Typically, the problem is addressed merely by generating a map of the memory space, that is, a memory "dump," showing the state of the memory blocks as they stood upon the termination of program execution. The usefulness of a memory dump is often nominal as it is based primarily upon static considerations and ignores valuable runtime information.

Therefore, what is needed is an approach to detecting leaked memory space in a computer program by employing a combination of runtime, dynamic memory searching and post-execution memory sweeping. Such an approach would enable the observation and analysis of dynamic program behavior as an adjunct to conventional memory sweeping.

Accordingly, the present invention enables the above problems to substantially be overcome by providing a method and system for dynamically detecting leaked memory space in a computer program.

Embodiments of the present invention are a method using a computer for, a system for and a storage medium encoded with computer readable program code for dynamically detecting leaked memory space in a computer program. The computer program comprises instrumentation routines for communicating runtime memory space conditions to a dynamic debugging system and has a memory space for storing dynamic data values. A dynamic leak search is performed for tracking allocated memory space using reference counting. A static leak sweep is performed for scanning blocks of the memory space to determine whether each such block of the memory space is reachable from another such block of the memory space.

A further embodiment of the present invention is a method using a computer for instrumenting a computer program to facilitate dynamic detection of leaked memory space in the computer program. The computer program is represented by code segments of source code written in a programming language. Each of the code segments of the source code are analyzed for determining an appropriate type of instrumentation routine for the computer program. A location within the source code is identified for placing a procedure call to the appropriate type of instrumentation routine. The instrumentation routine comprises one of a memory searching routine or a memory scanning routine. Each code segment of the source code is instrumented with the procedure call. Object code is generated from the instrumented source code for execution on the computer in conjunction with a dynamic debugging system.

Still other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only embodiments of the invention by way of illustration of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modification in various obvious respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

FIG. 1 is a functional block diagram of a system for dynamically detecting leaked memory space in a computer program constructed in accordance with the present invention;

FIG. 2 is a block diagram, by way of example, of the memory space used by a computer program;

FIG. 3 is a flow diagram showing, by way of example, abstract computer program segments before and after instrumentation;

FIGS. 4A and 4B respectively show computer source code listings before and after instrumentation for performing a leak search;

FIGS. 5A and 5B respectively show computer source code listings before and after instrumentation for performing a leak sweep;

FIG. 6 is a flow diagram of a method for dynamically detecting leaked memory space in a computer program performed in accordance with the present invention;

FIG. 7 is a flow diagram of a leak search routine;

FIG. 8 is a flow diagram for an adjust reference count routine;

FIG. 9 is a flow diagram of a search with reset routine;

FIG. 10 is a flow diagram of a search without reset routine;

FIG. 11 is a flow diagram of a leak sweep routine;

FIG. 12 is a flow diagram of a scan non-dynamic memory routine; and

FIG. 13 is a process "ToDo" list routine.

Referring to FIG. 1, a functional block diagram of a system 10 for dynamically detecting leaked memory space in a computer program constructed in accordance with the present invention is shown. The system 10 comprises a central processing unit (CPU) 11 interconnected to a memory 14, such as a random access memory, and a device for displaying error messages 15, such as a printer or display monitor.

The computer program is instrumented to generate a runtime program 12, such as described in related U.S. Pat. No. 5,581,696, the disclosure of which is incorporated herein by reference. The runtime program 12 contains the source code of the original computer program augmented with additional function or procedure calls required to communicate runtime conditions to a dynamic debugging system 13. The instrumentation includes appropriate checks for runtime or dynamic errors or programmatic anomalies that are communicated to the dynamic debugging system 13 in the form of debugging output and error messages, although other forms of instrumentation are feasible. The particular instrumentation required to perform memory leak searching and sweeping in accordance with the present invention is further described hereinbelow beginning in FIGS. 4A and 4B.

Typically, memory space is needed for storing the various parts of runtime program 12, including the generated target program code (or text), static and dynamic data objects, and a control stack for maintaining procedure activation records. Referring to FIG. 2, a block diagram of one manner, by way of example, of organizing the memory space 20 of the runtime program 12 is shown, although other forms of memory space organization are possible. The memory space 20 is divided into five separate areas. First, memory space is allocated, preferably at compile time, for storing global and statically allocated data objects 21. Next, memory space is allocated for the heap and dynamically allocated data objects 22 and the stack 23. Typically, the heap and dynamic data object storage area 22 and stack 23 occupy a contiguous block of memory space 20, although the heap and dynamic storage area 22 grows "downward," that is, towards higher memory addresses, and the stack 23 grows "upward," that is, towards lower memory addresses. The particular form of memory organization is programming language dependent and not all languages require memory space for a heap or stack. Next, the program code is stored in the text storage area 24. Finally, if employed by the runtime program 12, memory space area is provided for shared memory 25. A problem arises during the execution of runtime program 12 when dynamically allocated memory space, such as from the heap and dynamic storage area 22, the stack 23 or the shared memory 24, is "leaked" due to dereferencing as further described hereinbelow.

To dynamically detect leaked memory, the runtime program 12 is augmented with instrumentation for communicating runtime information to the dynamic debugging system 13. Referring to FIG. 3, a flow diagram, by way of example, of abstract computer program source code segments before and after instrumentation is shown. In this example, an uninstrumented program segment 30 comprises three groups of program statements A, B, and C, respectively represented by circles 32a, 33a and 34a. Before any instrumentation is introduced, the source code comprising the computer program is analyzed for determining the appropriate types of instrumentation routines required and for identifying the location within the source code for placing the function or procedure calls to the instrumentation routines. In the described embodiment, the uninstrumented source code 30 is instrumented to generate instrumented source code 31 containing instrumentation routines for dynamically preprocessing and postprocessing runtime information, although, preprocessing and postprocessing may not both be required in every case. As shown, code segment 32a is instrumented with preprocessing routine 32b and postprocessing routine 32c. Likewise, code segments 33a and 34a are respectively instrumented with preprocessing routines 33b and 34b and postprocessing routines 33c and 34c. The particular type of instrumentation routines employed are application dependent based on the requirements of the particular dynamic debugging system 13 used.

In the described embodiment, a hybrid technique for dynamically detecting leaked memory space, or simply, "leaks," is employed using both leak searching and leak sweeping instrumentation routines. With leak searching, a "reference count" of the number of pointer variables that are currently pointing to a given block of allocated memory space is maintained. Each manipulation of a pointer variable to a dynamic memory block is counted. In this manner, memory space is "searched" and noncyclic leaks are detected. A drawback of reference counting is that it is a poor technique for detecting a cycle. For example, suppose a memory block A contains a pointer a and a second memory block B contains another pointer b. A cycle occurs when, for instance, pointer a points to memory block B and pointer b points to memory block A. In this case, both dynamic memory blocks have a reference count of one but neither is accessible. A solution to this problem is to perform a static memory sweep by scanning all available memory blocks for addresses and unless the memory block is reachable from another "reachable" memory block, the memory block is considered not reachable, hence, leaked, regardless of the reference count. Consequently, the leak is detected.

Referring to FIGS. 4A and 5A, source code listings of example computer programs before instrumentation are shown. Referring to FIGS. 4B and 5B, source code listings of example computer programs after instrumentation are shown.

FIG. 4A shows a first example computer program written in the C++ programming language which declares an external procedure store.sub.-- pointer () (line 1) and a main program main () (lines 3-11). The same program is shown in FIG. 4B augmented with procedure calls to the necessary instrumentation routines for performing dynamic leak detection in accordance with the present invention. Referring to FIG. 4B, a postprocessing instrumentation routine .sub.-- Insight.sub.-- decl.sub.-- lwptr () is called (line 6) after the declaration of a dynamic pointer variable a (line 5). A second postprocessing instrumentation routine .sub.-- Insight.sub.-- assigna () is called (line 9) after the assignment of dynamically allocated memory space to the dynamic pointer variable a (line 8). Both a preprocessing instrumentation routine .sub.-- Insight.sub.-- call () and a postprocessing instrumentation routine .sub.-- Insight.sub.-- after.sub.-- call () are called (lines 10 and 12, respectively) for a procedure call (line 11) to the externally declared procedure store.sub.-- pointer () (line 1). Both preprocessing and postprocessing instrumentation routines are required for communicating the status of the memory space before and after the externally declared procedure store.sub.-- pointer () is called because it is not instrumented and therefore not in communication with the dynamic debugging system 13. A preprocessing instrumentation routine .sub.-- Insight.sub.-- assign.sub.-- ptr2 () is called (line 13) before the assignment of a static value to the dynamic pointer variable a (line 14). Finally, a postprocessing instrumentation routine .sub.-- Insight.sub.-- prog.sub.-- end () is called (line 15) to perform a leak sweep upon the completion of the main program main () (lines 3-17).

FIG. 5A shows a second example computer program also written in the C++ programming language which declares a data structure A (lines 1-3), a procedure leak () (lines 5-13) and a main program main () (lines 15-18). The same program is shown in FIG. 5B augmented with procedure calls to the necessary instrumentation routines for performing dynamic leak detection in accordance with the present invention. Referring to FIG. 5B, two postprocessing instrumentation routines .sub.-- Insight.sub.-- decl.sub.-- lwptr () are called (lines 7 and 8, respectively) after the declaration of a pair of dynamic pointer variables a and b (line 6). A second postprocessing instrumentation routine .sub.-- Insight.sub.-- assigna () is called (line 11) after the assignment of dynamically allocated memory space to the dynamic pointer variable a (line 10). A third postprocessing instrumentation routine .sub.-- Insight.sub.-- assigna () is called (line 13) after the assignment of dynamically allocated memory space to the dynamic pointer variable b (line 12). A preprocessing instrumentation routine .sub.-- Insight.sub.-- assign.sub.-- ptr () is called (line 14) before the reassignment of the memory block address stored in dynamic pointer variable b to the dynamic structure pointer a-<next (line 15). A second preprocessing instrumentation routine .sub.-- Insight.sub.-- assign.sub.-- ptr1 () is called (line 16) before the assignment of the memory block address stored in dynamic pointer variable a to the dynamic structure pointer b->next (line 17). Finally, a postprocessing instrumentation routine .sub.-- Insight.sub.-- prog.sub.-- end () is called (line 18) to perform a leak sweep upon the completion of the procedure leak () (lines 5-20).

Referring to FIG. 6, a method for dynamically detecting a memory leak constructed in accordance with the present invention is shown. A hybrid technique of leak searching using memory searching (also known as "reference counting") and memory sweeping is employed. The purpose of this method is to enable the dynamic debugging system 13 to automatically detect leaks at runtime with incomplete information about the status of memory space usage. Execution of the runtime program 12 starts in the normal fashion (block 60). If the manipulation of a dymanic pointer variable occurs (block 61), a leak search is performed (block 62) as further described hereinbelow in FIG. 7. Next, the original instrumentation routines for performing other types of dynamic debugging are optionally performed (block 63). Upon program termination (block 64), a leak sweep is performed (block 65) as further described hereinbelow in FIG. 11.

Referring to FIG. 7, the routine for performing leak searching (block 62) is shown. Its purpose is to track allocated memory space using reference counting. If the value stored in a pointer variable is passed or returned (block 70), the pointer variable is marked as potentially suspect and a "NoLeak" attribute is set (block 71). Each time a memory pointer is passed to or returned from uninstrumented code, the pointer is marked as potentially suspect because the uninstrumented code may have saved a handle to a memory block which would otherwise go undetected by the dynamic debugging system 13. This is noted by the "NoLeak" attribute. If the pointer variable is assigned a new value (block 72), the reference count is adjusted (block 73) as further described hereinbelow in FIG. 8. If the reference count for the pointer variable becomes zero (block 74) and the "NoLeak" attribute is set (block 75), the memory space is searched with a potential reset of the "NoLeak" attribute (block 76) as further described hereinbelow in FIG. 9. Otherwise, if the reference count equals zero (block 74) yet the "NoLeak" attribute is not set (block 75), a memory search without a possible reset of the "NoLeak" attribute is performed (block 77) as further described hereinbelow in FIG. 10. Note other methods of reference counting are possible, so long as some predetermined condition is used for indicating that a memory leak may exist.

Referring to FIG. 8, the routine for adjusting the reference count (block 73) is shown. Its purpose is to perform straight reference counting for maintaining a count of references to dynamically allocated memory blocks. If a pointer variable points to a newly allocated memory block (block 80), the reference count is incremented by one (block 81). If a new value has been assigned to the pointer variable, thereby eliminating the reference to the old memory block (block 82), the reference count is decremented by one (block 83).

Referring to FIG. 9, the routine for searching memory space with an optional reset of the "NoLeak" attribute (block 76) is shown. Its purpose is to search the memory space for a pointer variable that points to the memory block in question for detecting a leak. First, the memory space is searched for a pointer to the memory block in question (block 90). If the pointer is found (block 91), the memory block is not leaked and, therefore, the "NoLeak" attribute is reset and no leak error is reported (block 92). If no memory block is found (block 91), a leak exists and a leak error is reported (block 93). If it cannot be determined whether a pointer exists, that is, it is "unknown" (block 91), no leak error is reported (block 94). The unknown case occurs when the symbol table is not being used or the memory allocation instruction is not trapped. In the described embodiment, these are options for the dynamic debugging system 13 that can be set by the user. In addition, some dynamic debugging systems employ symbol readers that have not been fully implemented and are only able to sweep some memory blocks. Since all memory blocks are not swept, a conclusive "YES" can only be issued if a pointer is found. Otherwise, the answer is "unknown" at best since all of the memory blocks were not searched.

Referring to FIG. 10, the routine for searching memory space without an optional reset of the "NoLeak" attribute (block 77) is shown. Its purpose is the same as the routine of FIG. 9 except the "NoLeak" attribute is not potentially reset. First, the memory space is searched for a pointer to the memory block in question (block 100). If the pointer is found (block 101), the memory block is not leaked and no leak error is reported (block 102). If no memory block is found (block 101), a leak exists and a leak error is reported (block 103). If it cannot be determined whether a pointer exists, that is, it is "unknown" (block 101), a leak also exists and a leak error is reported (block 104).

Referring to FIG. 11, the routine for performing a leak sweep (block 65) is shown. Its purpose is to scan all available memory blocks for addresses to determine whether they are reachable from another memory block that is itself "reachable." If a memory block cannot be reached from another memory block, then it has been leaked, regardless of the reference count. This routine is performed statically upon the completion of the execution of the runtime program 12. First, a "Leaked" attribute is set for all memory blocks (block 110). Next, all non-dynamic memory, that is, globals and statics 21 and parts of the stack 23, are scanned for memory addresses (block 111) as further described hereinbelow in FIG. 12. A "ToDo" list is generated during the scan and processed upon the completion of the scan (block 112) as further described hereinbelow in FIG. 13. Finally, all memory blocks with the "Leaked" attribute set are reported as having been leaked (block 113).

Referring to FIG. 12, the routine for scanning non-dynamic memory (block 111) is shown. Its purpose is to search a region of memory space for a memory address. It begins by looking for pointer-sized pieces of memory within each memory block (block 120). A "pointer-sized" piece of memory is a set of contiguous memory locations having a specific size particular to the machine architecture in which a memory pointer can be stored. For example, Sun workstations employ memory pointers that are four bytes (32 bits) in size. Consequently, the memory space is subdivided into four-byte pieces, each of which is assumed to be a pointer during the scanning process.

In the described embodiment, memory space can be searched in one of two ways. First, the memory space can be scanned for a pointer to all addresses corresponding to the beginning of a memory block. Second, the memory space can be searched for a pointer to all addresses corresponding to the beginning of a memory block or any other address within a memory block. If a pointer-sized memory piece is found (block 120), the address for the memory block is looked up (block 121).

There are three possible outcomes from a memory search. Either a pointer to the memory block was found, not found, or it was not possible to generate a conclusive answer. In the described embodiment, whenever a memory block "address" is found, a programmer-supplied filter is used to check the address for validity since the memory scanning assumes that all aligned pointer-sized memory pieces are pointers. The filter is used to help separate out pointer-sized pieces of memory that are not true memory addresses. Filtering also includes avoiding memory space which contains temporary variables or other items known not to actually be pointers, such as an array of characters that happen to contain the same pattern as a memory block address. Filtered "hits" do not count.

Preferably, a filter could, for example, look up an address in the symbol table and determine that it really is part of a character array and that the "hit" was accidental rather than actual. The programmer-supplied filter allows this to be accomplished. Thus, upon obtaining the memory blocked address, the routine will determine whether the "Leaked" attribute is set (block 122). If so, the "Leaked" attribute is cleared and the memory block is added to the "ToDo" list (block 123). Otherwise, if the "Leaked" attribute is set (block 122), the routine continues. The routine repeats until the last memory block has been processed (block 124).

Referring to FIG. 13, the routine for processing the "ToDo" list (block 112) is shown. Its purpose is to process each memory block in the "ToDo" list in a breadth first search manner, although other searching methodologies, including depth first searching, are feasible. First, the memory block is removed from the "ToDo" list (block 130). Next, the non-dynamic memory is scanned using the memory block obtained from the "ToDo" list (block 111) as shown in FIG. 12. The routine continues until the "ToDo" list is emptied (block 131). When the "ToDo" list is empty, all memory blocks marked with the "Leaked" attribute are known to be leaked and reported to the user.

While various embodiments of the invention have been particularly shown, it will be understood by those skilled in the art that the various changes in form and detail may be made without departing from the scope and spirit of the present invention, wherein: