Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-02-25
2003-02-18
Beausoliel, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S049000, C717S124000, C707S793000, C711S170000
Reexamination Certificate
active
06523141
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of Invention
The present invention relates generally to the allocation of memory in computing systems. More particularly, the present invention relates to identifying and reporting memory leaks in computing systems.
2. Description of the Related Art
The amount of memory, both statically allocated memory and dynamically allocated memory, available to a computing system or, more specifically, processes executing on the computing system, is limited. As such, different processes must typically share memory resources. In order for memory to be shared, memory is recycled. In other words, a section of memory which is no longer used by one process may be reclaimed and allocated for use by another process.
A kernel is privileged mode or “supervisor” software which executes for the lifetime of a machine, e.g., a computing system. During normal operation, a kernel typically dynamically allocates data structures. When allocated dynamic data structures are no longer needed within a computing system, the dynamic data structure will ideally be explicitly freed, as will be understood by those skilled in the art. Only “reachable” memory, i.e., memory that may ultimately be reached from a kernel data module such as a buffer or a thread stack, may be freed. It should be appreciated that “unreachable memory, i.e., memory that may not be reached from a kernel data module, may not be freed. Such “unfreeable” memory typically constitutes a memory leak.
FIG. 1
is a diagrammatic representation of a section of dynamically allocated memory with unreachable pieces of memory. A section of dynamically allocated memory
120
includes sections
124
,
126
. Sections
124
are considered to be reachable, as sections
124
may be traced back to a module data section
110
such as a buffer or a thread stack. In other words, sections
124
may be traced back to a root set, as will be understood by those skilled in the art. For example, section
124
f
may be traced back to module data section
110
b
through sections
124
b
and
124
e.
Sections
126
are considered to be unreachable since sections
126
may not be traced back to a module data section
110
, e.g., are not traceable back to a root set.
Reachable sections
124
are explicitly freed when reachable sections
124
are no longer being used. Unreachable sections
126
may not be explicitly freed by a kernel, and are difficult to identify. Unreachable sections
126
often result in memory leaks, as unreachable sections
126
are sections of memory which may not be explicitly freed and, hence, may not be reallocated for other uses.
Because the available memory in a computing system is reduced, memory leaks generally cause an operating system to operate more slowly. When the overall amount of leaked memory is high, memory leaks may eventually result in no memory being available for allocations. When memory is no longer available for allocations, a kernel may hang indefinitely while waiting for memory to become available. Typically, unless a memory leak causes an overall machine failure, memory leaks are difficult to locate. By way of example, a memory leak may be manifested as a few bytes, e.g., eight bytes or less, in an error path. A few missing bytes typically does not appear to be important and, hence, the memory leak may be overlooked.
One standard method of identifying memory leaks involves looking at “buckets” of memory to identify a bucket which includes an abnormal number of allocations. A bucket that includes an abnormal number of allocations is considered to be likely to include memory leaks. For instance, if a bucket includes many more allocations than typically expected, the indication may be that additional memory is allocated because of memory leaks. Once memory leaks, or potential memory leaks, are identified, memory leaks may be fixed by modifying the errant code to explicitly free memory that is no longer in use. It should be understood that any suitable method may generally be used to fix memory leaks. By way of example, a programmer may modify the source code for an operating system in order to explicitly free memory which was leaked.
Searching for memory leaks is often inefficient, as methods used to locate memory leaks are time-consuming and often inaccurate. By way of example, searching buckets of memory and identifying an unusual number of memory allocations in order to identify likely memory leaks is a subjective process. Further, identifying memory leaks by identifying an abnormal number of memory allocations is typically effective only in finding frequent or large memory leaks. That is, studying the number of memory allocations, in general, is relatively ineffective in identifying memory leaks which are not associated with frequently executed code or are not large buffers leaked by a kernel. Studying the number of memory allocations is relatively ineffective in identifying infrequent or small memory leaks, e.g., memory leaks associated with a rarely executed code path or memory leaks such as a single byte that is leaked only once.
Failing to detect and to correct infrequent or small memory leaks may result in significant problems. For example, if a rarely executed code path that has associated memory leaks is eventually executed frequently, the associated memory leaks may lead to a significant slowing of the overall computing system and, eventually a crash of the system. In addition, many infrequent or small memory leaks may eventually cause enough overall memory leakage to cause a system failure.
Therefore, what is desired is a method and an apparatus for efficiently detecting memory leaks. More specifically, what is needed it an effective method and apparatus for identifying and correcting infrequent and small memory leaks.
SUMMARY OF THE INVENTION
The present invention relates to methods and apparatus for detecting and reporting memory leaks associated with an operating system. In accordance with one aspect of the present invention, a method for identifying a section of leaked dynamically allocated memory includes obtaining information associated with a failure of an operating system and identifying a function that may be associated with the section of the dynamically allocated memory using the information. Once the function is identified, a determination is made as to when the function is actually associated with the section of the dynamically allocated memory. In one embodiment, obtaining information associated with a failure of the operating system includes obtaining an image of the operating system which is created when a kernel associated with the operating system crashes.
In another embodiment, when it is determined that the function is associated with the section of the dynamically allocated memory, the method further includes determining the source of the leaked dynamically allocated memory. In such an embodiment, determining the source of the leaked section of the dynamically allocated memory includes obtaining a plurality of pointers associated with the dynamically allocated memory and placing the plurality of pointers into a data structure. Once the plurality of pointers are placed in the data structure, a first pointer included in the plurality of pointers is identified as being associated with the section of the dynamically allocated memory. The first pointer is then removed from the data structure, thereby enabling the section of the dynamically allocated memory to be located and subsequently freed.
According to another aspect of the present invention, a method for locating a section of unreachable memory associated with a computing system includes obtaining information associated with a failure of an operating system arranged to run on the computing system. Once the information is obtained, a function that is potentially associated with the section of unreachable memory is identified off-line using the information. It is then determined when the function is associated with the section of unreachable memory. Determining when the function is associated with the section of u
Beausoliel Robert
Beyer Weaver & Thomas LLP
Puente Emerson
Sun Microsystems Inc.
LandOfFree
Method and apparatus for post-mortem kernel memory leak... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for post-mortem kernel memory leak..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for post-mortem kernel memory leak... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3152314