WO1993003435A1

WO1993003435A1 - Method and apparatus for identifying memory leaks and tracking pointers in a computer program

Info

Publication number: WO1993003435A1
Application number: PCT/US1992/006419
Authority: WO
Inventors: Reed Hastings; John Dawes
Original assignee: Pure Software, Inc.
Priority date: 1991-08-08
Filing date: 1992-08-03
Publication date: 1993-02-18
Also published as: AU2423092A

Abstract

A library of specialized routines (3) is described herein, some routines of which implement the malloc interface (110, 120, 130, 140). The malloc interface routines also label each allocated bloc with several items of information, including a partial call chain beginning with the caller of malloc. Other routines use the information present in the label to track pointers and memory leaks, so as to help a programmer debug a program. In its most basic form, the method of tracking memory leaks includes the steps of: associating allocated blocks with partial call chains (510); marking allocated blocks with partial call chains (520); marking accessible allocated blocks (560); searching memory for unmarked allocated blocks (570); and, reporting partial call chains of unmarked allocated blocks (580).

Description

METHOD AND APPARATUS FOR IDENTIFYING MEMORY LEAKS

AND TRACKING POINTERS IN A COMPUTER PROGRAM

BACKGROUND OF THE INVENTION The present invention relates generally to a method and apparatus for analyzing and debugging memory usage by a computer program. In particular, the present invention relates to a debugging tool for identifying pointers and memory leaks in a computer program. Most particularly, the present invention relates to an interactive debugging tool for identifying the origination of pointers and the origination and size of memory leaks in a computer program.

Many programmers write software programs that use libraries for dynamic memory allocation. When a program part needs more dynamic memory, it specifies the desired amount of memory to an allocation library routine, which allocates a block of memory of the desired size and returns a pointer to it. The libraries typically require each program part to explicitly deallocate, or "free", its dynamic memory when the program part is finished using that memory. Deallocating the memory permits the library routines to reclaim that memory, and give it out to another program part later on.

A common source of errors in a program is for a program part to fail to deallocate memory when it should have; this is called a memory leak. For the lifetime of the program, at least, this leaked memory accumulates. If enough memory accumulates, the program will run out of memory while it is still running and will typically crash; other programs running on the same computer might crash as well. The types of situations in which memory should be freed varies from system to system. In a "protected-memory" system the system automatically reclaims all of a program's memory when it terminates. Thus, the program need only avoid accumulating too much memory while it is running. The typical method of avoiding memory accumulation is to free memory once it is no longer needed. A memory block can be freed so long as a pointer to the block's beginning still exists; however, once the last pointer to a block has been lost, such as by being overwritten, the block cannot be freed and it is leaked. This "lost pointer" memory leak can even happen when programmers intended to free blocks, if they failed to correctly anticipate program flow.

Programs running on nonprotected-memory systems are subject to a broader range of memory leaks. The system has no way of automatically freeing memory when a program exits, so the program is supposed to free all allocated memory before terminating. If the program does not do this, the memory remains allocated and wasted until the system is re- initialized.

The "lost pointer" memory leaks can occur on all systems, so they will be termed "pan-system" memory leaks; the other memory leaks, which only occur at exit time on nonprotected-memory systems, will be termed "exit time" memory leaks. Because nearly all modern mainframe computers and workstations are protected-memory systems, the main concern of this discussion is the problem of avoiding pan-system memory leaks.

Finding memory leaks is very difficult, since at any one time there can be thousands of memory blocks in use.

Moreover, while statically allocated memory is named by the programmer ("employee_record_table", for instance) so that it can be referenced from code, dynamically allocated memory is anonymous. Dynamically allocated memory blocks are only identified by their address and sometimes their size. Their address is unpredictable, and contains little information. Their size can be useful, but frequently there are dozens of data structures of the same size, so the block size rarely identifies the block type. Determining the presence of leaks can be done by watching the total memory allocated over a span of many repetitions of a given program part. It can be very difficult, however, to find ways to repetitively exercise each program part. Furthermore, while this method may confirm the presence of leaks, it is not easily used to track them down. Once a leak is detected, shorter and shorter sections of code must be exercised until the leak disappears. Then, the section of code most recently removed from the exercised loop is examined. In typical commercial code, it can easily take a day or more to track down a single memory leak in this manner.

One tool designed for analyzing the dynamic memory allocation behavior of programs, including some memory leak detection, is described by Zorn and Hilfinger ("A Memory

Allocation Profiler for C and Lisp Programs", Summer USENIX 88 Proceedings). This tool has its own version of 'malloc' (a dynamic memory allocation routine) that for memory leak detection records the first five return addresses on the call stack, which identify the the chain of functions that led to 'malloc' being called and which together are termed a partial call chain. The tool makes a hash table whereby each partial call chain is keyed to a structure. Each structure tracks the blocks allocated by the partial call chain and holds an 'Allocated' counter and a 'Freed' counter. Whenever a block of memory is allocated, the tool stores (just before the block's first byte) the size of the block, in addition to a pointer to the structure corresponding to the partial call chain. Also, the 'Allocated' counter of this structure is incremented. Whenever a block is deallocated, the corresponding 'Freed' counter is identified by the pointer at the beginning of the block and incremented. When the program exits, each structure in the hash table is written to a file. A monitor program can then be run to examine this information. If a structure's 'Freed' counter is N less then its 'Allocated' counter, then a report is made that N blocks from the corresponding call chain were never freed.

Zorn's tool lists both pan-system memory leaks and exit time memory leaks; however, the tool has no way to distinguish the two. This is useful for nonprotected-memory systems, but for protected memory systems it renders the tool nearly useless. On these systems, exit time "memory leaks" (which are not really memory leaks on these systems) often overwhelm pan-system memory leaks, making Zorn's tool register too many "false positives" to be useful for tracking down pan- system memory leaks.

One way to avoid memory leaks altogether is use a language such as Lisp, which does not employ explicit deallocation. In these languages memory deallocation and reclamation is done by a "garbage collector", which looks at the program memory to determine which blocks are no longer being used, and returns them to the system. A common method for garbage collecting is known as " ark-and-sweep". With this method the data and stack sections of the program memory are examined for all potential pointers (words whose value is a valid address) into the heap. If a potential pointer points to an allocated block in the heap, that block is marked as in-use, and all potential pointers within the block are recursively examined in the same manner. Then, the entire heap is examined, and all allocated blocks no longer in-use, now garbage, are freed.

Garbage collectors have been implemented in a variety of languages, but in many, only imperfectly. Un ortunately, in all languages garbage collectors tend to slow down program execution, and the languages for which they work best are often disfavored by programmers for other reasons. For these reasons many programmers choose not to use garbage collectors, and attempt to rely on explicit memory deallocation. For this, programmers, especially on protected memory systems, need a development tool that can help them identify pan-system memory leaks.

A related problem, which surfaces while tracking down many types of programming errors, is determining the type of data pointed to by a pointer. Some languages assign fixed types to pointers, but C and C++, for example, have a generic pointer type "void*", and through casting they allow pointers to be copied from one type to another. Pointers are frequently copied across types, especially to the void* type, making it difficult to get useful information simply from a type tag. A typical case is that a pointer gets cast as a void* generic pointer, and is then passed around from function to function. A programmer looking at the pointer during interactive debugging would in many contexts only know it to be of type void*, and would have little indication of the nature of the item to which it pointed or from where it originated.

SUMMARY OF THE INVENTION One aspect of the invention is directed to identifying memory blocks that are allocated, but are no longer in use and cannot be freed because there is no accessible pointer to them. These blocks are pan-system memory leaks. According to this aspect of the invention allocated blocks are associated with partial call chains; allocated blocks are marked accessible; memory is searched for unmarked allocated blocks and partial call chains of unmarked allocated blocks are reported.

In one embodiment each memory block is labelled when it is allocated. The label includes a partial call chain to identify from where the block was allocated. The partial call chain can be translated into function names and line numbers via debugging information in the symbol table to provide the programmer with information about the memory block. When memory leaks are to be identified, a marking procedure basically the same as the "mark" part of "mark-and-sweep" is performed. Finally, each allocated block is examined. If not marked as accessible the block is a leak, and its partial call chain is printed with an informative message that can include source line identification to help the programmer locate the source of the leak. The memory leak searching identifies pan-system memory leaks and excludes exit-time memory leaks. It may be controlled by the programmer so as to be performed several times within one execution of the monitored program, which makes it valuable even on a nonprotected-memory system. The information thus gained allows the programmer to fix memory leaks at development time, so that the use of a sluggish garbage collector is not required by the end user. Another aspect of the invention is directed to interactively identifying the nature of a pointer and the memory block to which it points. Memory blocks are labelled with partial call chains as described above. A tool constructed according to the invention supplies a function that can be called from a debugger, or from the program, that takes a pointer as an argument and looks up and prints the partial call chain of the corresponding block, again, optionally with source lines. This is often sufficient to completely identify the nature of the pointer.

A further understanding of the nature and advantages of the invention may be realized by reference to the remaining portions of the specification and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a computer program being linked according to the invention;

Fig. 2 is an illustration of a block labelled according to the invention; Fig. 3 shows a sample output of pointer identification according to the invention;

Fig. 4 shows a sample output from memory leak detection according to the invention;

Fig. 5 is a flowchart for a 'malloc' routine of the preferred embodiment;

Fig. 6 is a flowchart for a 'free' routine of the preferred embodiment;

Fig. 7 is a flowchart for a memory leak detection routine of the preferred embodiment; Fig. 8 is a state diagram illustrating the operation of a program linked with the preferred embodiment; and

Fig. 9 is a flowchart for the mark_block routine of the preferred embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENT The preferred embodiment is implemented on a Sun3 workstation from Sun Microsystems, Inc., of Mountain View, California. It is designed to work with C & C++ programs, which use the malloc library interface to manage dynamic memory. The standard documentation for that interface is available.

The preferred embodiment comprises a library of routines based on the standard malloc interface. There are a number of public domain malloc interface packages with source code available, or one can be obtained from Sun with a source code license to Sun OS. The routines of the preferred embodiment implement the malloc interface and in addition allocate extra bytes to label each block. These extra bytes are filled with the saved program counter values from the calling stack frames. The depth recorded may be controlled by the value of an environment variable, and its default is 6.

The modified library also includes pointer/memory-leak tracking routines that use the information provided by the modified malloc interface.

Fig. 1 shows a program 1 being linked by a computer 2 with a malloc interface library 3 according to the invention to produce a self-memory-leak-monitoring program 4 according to the invention. The program is now- equipped to provide a great deal of useful debugging information to the programmer.

The MallocHeader

Each malloc request in the preferred embodiment produces a labelled block of memory structured as illustrated in Fig. 2, and indicated generally by reference numeral 5. The header ("MallocHeader") , or label, 6 contains a four byte identifier value 7 identifying this as a MallocHeader, a four byte length value 10 specifying the length the user requested (N) , a mark field 15, and four bytes for each of the return addresses. Return address 20 is the address of malloc's caller, and return addresses 21 are the remaining addresses of the partial call chain. The length of the MallocHeader is twelve bytes plus four bytes per address in the partial call chain. In the preferred embodiment the partial call chain is six addresses long, so a request to malloc for N bytes results in N + 36 bytes being allocated, with the first 36 forming the header. The byte just above the header, indicated by reference numeral 30, is the beginning of the N byte user's block 50.

The information found in the MallocHeader can be used to provide useful information about both pointers and blocks to the programmer. For example, if a program were failing at a particular point because a routine was expecting a pointer to a different type of data than what was actually passed, the programmer would have a difficult time determining the source of the pointer just from examining the contents of the pointed- to memory without knowing its format. The MallocHeader, however, can be used to precisely pinpoint the origin of the block of memory, from which its format (the nature of its contents) and the origin of the pointer to the memory can be determined. Fig. 3 shows a sample output of pointer identification according to the invention. As mentioned earlier, locating the source of memory leaks can also often be very difficult, and the MallocHeader aids in this as well. The MallocHeader provides the information that is used to make the memory leak detection report shown in Fig. 4. This informative report significantly eases the burden of tracking down unruly memory leaks, as will be discussed in further detail below.

The malloc Interface The memory allocation function malloc takes one argument, N, the number of bytes needed by the program. The operation of the preferred embodiment's modified malloc routine is illustrated in Fig. 5. In block 110, a block of memory large enough for the MallocHeader and the user's N bytes is allocated. In block 120, the MallocHeader mark, identifier, and length fields are initialized. The mark is initialized to a reset state; the identifier, to the hexadecimal value Oxbadbadad (or some other predetermined identifier value) ; and the length, to N. In block 130, the partial call chain entries in the MallocHeader are initialized by following the frame pointer chain. More specifically, the frame pointer is the address of the beginning of the call chain. The 4 bytes pointed to by the frame pointer are the previous frame pointer. and the 4 bytes above the previous frame pointer are the saved program-counter values (the return address) of the current frame. In block 130, the frame pointer chain is followed, and each saved return address is stored into the MallocHeader. Then, in block 140, pointer 30 of Fig. 2 is returned to the user's N bytes.

The operation of the preferred embodiment's modified free routine is illustrated in Fig. 6. This routine takes one argument, a pointer to the block to be freed. In block 210, the label identifier is reset to some value other than the predetermined identifier value ( in this case Oxbadbadad) , so that the block is no longer marked as an allocated block. Next, in block 220, the entire block and label are freed. The routine then returns^'. Malloc and free are the memory allocation primitives, but there are several memory access convenience functions in the malloc interface (such as realloc) . The preferred embodiment's versions of these call malloc and free to allocate and deallocate memory, and thus memory allocated with them also has a MallocHeader.

Findleaks

In the preferred embodiment a function findleaks is supplied, which works as illustrated in Fig. 7. In block 305 the function mark__block is called and passed the beginning and end of the active portion of the stack segment as arguments. Mark_block recursively searches for accessible allocated memory blocks, with the given memory range as the starting accessible block; all accessible blocks found then have their mark set. The operation of mark_block is described in further detail below with reference to Fig. 8. Next, in block 310, mark_block is called again with the data segment. After this, all accessible memory blocks have been marked, because they must have a pointer path originating in either the data or stack segments. Then, the heap is searched for inaccessible allocated blocks. The preferred embodiment starts at the low end of the heap and in block 320 selects the first group of four bytes. These bytes are then examined in block 330. If they do not match the block identifier value (Oxbadbadad in the preferred embodiment) , then block 340 checks to see if the entire heap has been checked. If so, the function exits in block 350. If not, the next group of four bytes is selected in block 360, and examined in block 330. In the preferred embodiment, every even byte address is checked as the beginning of a four byte group. If a group matches the block identifier value, then block 370 checks if the label mark is set. If so, then this is an accessible block and the mark is simply reset in block 380, after which control passes to block 340. If the label mark was not set, then this is a block not found by mark_block, and is a pan-system memory leak. In block 390 the pan-system memory leak is reported along with its length, address, and partial call chain, all taken from the block label. If desired, the block identifier of the memory leak can be reset, so that the memory leak will not be reported again in a later check. Control then passes to block 340. The findleaks routine may be called automatically by the program at periodic intervals, or it can be called through a debugger. If the program is being tested interactively through a debugger, the programmer can immediately use the reported information to examine the block and try to determine where it originated. They can then rerun just the portion thought to have been responsible and then look for new leaks, to see if that portion had indeed been responsible. This allows a source of memory leaks to be rapidly located.

The pointer identification routine shares a great deal with the findleaks routine. Indeed, its steps are a subset of the steps performed by findleaks and mark_block. The routine takes a single pointer as an argument. It searches backwards from the memory location pointed to by its argument, examining each possible location for the presence of a block identifier. Once a block identifier is found, the block's length is examined. If the routine's argument points to a location within the block, then the block's partial call chain is reported; otherwise, it is reported that the argument does not point to a valid memory location (although the block's partial call chain may still be reported) . Mark-block

The mark_block routine will now be described with reference to Fig. 8. Mark_block has two arguments, the beginning and end addresses of a block which is given as accessible by the program. Block 400 is the beginning of the mark_block routine. In block 405, a variable X is set to the beginning address passed to mark_block. A variable P is next set equal to the 4 bytes pointed to by X. P is treated as if it is a pointer, since there is no way to distinguish pointers from other 4 byte values. In block 415 P is checked to see if it points into the heap. If not, control passes to block 420, where X is incremented by 2 (pointers typically can only be directly stored at even addresses) . Next, in block 425, X is compared to the end of the block to see if there is space within the block for a pointer located at X. If not, then in block 430 mark_block returns. If, back at block 415, P had pointed into the heap, then control would have passed to block 435, which searches backwards from the location pointed to by P, until either a block identifier value is found or the beginning of the heap is found. If block 440 determines that a identifier was not found, then P did not point into an allocated block, and control passes to block 420. If a identifier was found, then in block 445 the length of the block, found in the MallocHeader, is used to determine if P points to a location within the block. If not, then control passes to block 420. If P does point within a block, then the block's accessibility mark in the MallocHeader is checked in block 450. If the mark is already set, then the block has already been searched by mark__block, and control passes to block 420. Otherwise, block 455 sets the mark, and block 460 recursively calls mark_block with the beginning and end addresses of this newly found accessible block. Once this call returns, control passes to block 420. In this manner mark_block is called recursively to follow all potential pointers and to mark any blocks found as accessible.

Program Operation The operation of a program linked with the routines of the preferred embodiment is illustrated by the state diagram of Fig. 9. State 500 includes most program operations. When a malloc is performed, state 510 is entered, in which memory for a labelled block is allocated. From state 510 execution passes to state 520, in which the label, which includes a block identifier, is initialized. State 520 leads to state 530, in which the pointer to the beginning of the user's portion of the block is returned at the same time that control returns to the calling function. When free is called it undoes the work of malloc: in state 540 the block identifier is reset, after which the entire block is deallocated in block 550. Control then returns to the calling function.

The findleaks routine may be called automatically by the program at periodic intervals or at certain points within the program; it may be triggered by a mouseclick, by a predetermined keystroke sequence from the user, or by the mouse not moving for a period of time; or, any of a variety of other events could trigger it. When it is called, state 560 is entered, in which all accessible allocated blocks are so marked. Control then advances to state 570, in which the entire heap is searched for allocated blocks that were not marked as accessible, and after which control proceeds to state 580, in which a report is made to the use. In the actual operation states 570 and 580 may be interleaved. Thereafter, control returns to the calling function.

The program may optionally be run with an interactive debugger, which is quite useful. The debugging state 590 can be entered in a variety of ways depending on the debugger, and the findleaks routine may be called directly from it.

Information reported by the findleaks routine may be used advantageously within the debugging state to track down and correct pointer/memory usage errors. It is also quite useful to use the methods and routines described herein in conjunction with a memory access monitor such as is described in the U.S. patent application "Method and Apparatus for Modifying Relocatable Object Code Files and Monitoring Programs", Ser. No. 07/718,573, filed June 21, 1991, which is, in its entirety. incorporated herein by reference, with particular attention called to pp. 14-21 and the Source Code Appendix filed with that application.

Variations and Alternative Embodiments

There are a variety of implementation alternatives, many of which work equally well. The 4 byte identifier value could just as well be some value other than Oxbadbadad. It could also be more or less than 4 bytes; the more bytes, the less likely that will occur by chance in the user's data. To totally eliminate this possibility of the identifier value appearing by chance, malloc and free could maintain a list of allocated blocks, and no identifier would be needed. Another possible use for a separate list or table would be to use Zorn's technique of hashing on the call chain to a single record rather than storing the partial call chain with each block. Since there are many blocks with the same call chain, space could be saved in this manner. This decision is primarily a time versus memory space trade-off. Another variation is that odd byte addresses could be checked in mark_block to search for additional pointers. Currently, only even byte addresses in mark_block are checked, since it is very rare to store a pointer at an odd-byte address. Including odd-byte addresses in the mark__block routine would significantly increase the number of non-pointer values treated as if they were pointers, which in turn could cause fewer memory leaks to be reported.

It is possible for the preferred embodiment to have false negatives, that is, to miss some pan-system memory leaks. If, for example, there is a character string of which some 4 bytes are equal to a value that points into the heap, and these 4 bytes happen to be the only pointer into a block, that block will incorrectly be omitted from the leak list. In practice, this happens quite seldom, and in the preferred embodiment it was judged to be more important that there be no false positives. One way to ameliorate the problem, however, is to only mark a block as in-use if there is a pointer to its beginning. A pointer to its beginning is needed to free the block, so any block whose beginning cannot be determined by the program cannot be freed. This greatly reduces the chance of a random bit pattern unintentionally marking a block, thereby reducing the false negatives. Unfortunately, a programmer might use a pointer into the middle of a block and keep an offset from it to point to the beginning; also, permanently allocated blocks can be handled without pointers to their beginning. So, if pointers were required to point to the beginning of a block to mark it as accessible, accessible and free-able blocks may show up in the leak list, since the program has no need to keep around a pointer to their beginning. This increases the false positives.

It is to be understood that the above description is intended to be illustrative only and not restrictive. Many other variations and embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

WHAT IS CLAIMED IS:

1. A method for detecting and identifying memory leaks in a computer program on a computer, said computer having a memory, said program having call chains resulting in blocks being allocated in the memory, said method comprising the steps of: a) associating allocated blocks with partial call chains; b) marking accessible allocated blocks; c) searching the memory for unmarked allocated blocks; and d) reporting partial call chains of unmarked allocated blocks.

2. The method of claim 1, wherein the allocated blocks have beginning addresses, and wherein the associating step comprises forming a hash table keying the partial call chains to the beginning addresses of the allocated blocks.

3. The method of claim 1, wherein the associating step comprises recording the partial call chains in labels attached to the allocated blocks.

4. The method of claim 3, wherein the marking step comprises setting a mark in the labels of accessible allocated blocks.

5. A method for detecting and identifying memory leaks in a computer program using a heap, comprising the steps of: a) on every call for a dynamic memory allocator to allocate a block of memory having a length, allocating the block and labelling with a header comprising i) an accessibility mark; ii) a chain of program counter values that led to the memory allocator call; iii) the block length; and iv) a block identifier value; b) determining which allocated memory blocks are accessible by performing the following steps for each potential pointer located outside of the heap v) determining if the pointer points into an allocated block; vi) if the allocated block's accessibility mark is not set, setting it and recursively performing steps v) and vi) for each potential pointer within the block; c) searching the heap for allocated blocks as identified by block identifiers, and if the block's accessibility mark is not set, reporting the block's size, length, and chain.

6. A method for identifying a pointer in a computer program on a computer, said computer having a memory, said program having call chains resulting in blocks being allocated in the memory, said method comprising the steps of: a) associating allocated blocks with partial call chains; and b) if the pointer points to a location within an allocated block, reporting the partial call chain of the allocated block.

7. A kit of routines for being linked with a computer program using a heap, and for debugging the computer program, said routines having call chains when called during program execution, said kit comprising: a) malloc routine means for allocating a block of memory with labels containing i) a partial call chain; ii) an accessibility mark; iii) a block identifier; and b) free routine means for deallocating a block of memory and resetting the block identifier of the block's label.

8. The kit of claim 6, wherein debugging includes detecting and identifying memory leaks in the computer program, further comprising a findleaks routine including: a) marking means for marking allocated blocks that are inaccessible to the computer program; b) searching means for finding marked allocated blocks; and c) reporting means for reporting the partial call chain of marked allocated blocks.

9. The kit of claim 7, further comprising a pointer identifier routine, said pointers pointing to locations in the heap, said pointer identifier routine including: a) means for searching backwards from the location pointed to by the pointer for a block identifier and its block; b) means for determining if the block contains the memory location; and c) means for reporting the partial call chain of the block.

10. The kit of claim 6, further comprising a pointer identifier routine, said pointers pointing to locations in the heap, said pointer identifier routine including: a) means for searching backwards from the location pointed to by the pointer for a block identifier and its block; b) means for determining if the block contains the memory location; and c) means for reporting the partial call chain of the block.