US20060212852A1 - Methods, systems and computer program products for detecting memory leaks - Google Patents

Methods, systems and computer program products for detecting memory leaks Download PDF

Info

Publication number
US20060212852A1
US20060212852A1 US11/081,910 US8191005A US2006212852A1 US 20060212852 A1 US20060212852 A1 US 20060212852A1 US 8191005 A US8191005 A US 8191005A US 2006212852 A1 US2006212852 A1 US 2006212852A1
Authority
US
United States
Prior art keywords
total size
childnode
largest
parentnode
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/081,910
Inventor
Jinwoo Hwang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/081,910 priority Critical patent/US20060212852A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HWANG, JINWOO
Publication of US20060212852A1 publication Critical patent/US20060212852A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3612Software analysis for verifying properties of programs by runtime analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory

Abstract

Methods of detecting a memory leak may include identifying a largest ChildNode of a ParentNode; and comparing a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode. If the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode, a possible memory leak area may be identified. Related systems and computer program products are also discussed.

Description

    BACKGROUND OF THE INVENTION
  • The present invention relates to data processing in general and, more particularly, to methods, systems, and computer program products for monitoring program code memory usage.
  • Object oriented programming is a well-known software application development technique that employs collections of objects or discrete modular data structures that are identified by so called references. More than one reference can identify the same object. The references can be stored in the application variables and within the objects, forming a network of objects and references, known as the reference graph. The objects are created dynamically during the application execution, and are contained in a memory structure referred to as a heap.
  • Many object oriented programming languages, such as JAVA®, Eiffel, and C sharp C#), employ automatic memory management, popularly known as garbage collection. Automatic memory management is an active component of the runtime system associated with the implementation of the object oriented language, which removes unneeded objects from the heap during the application execution. An object is unneeded if the application will no longer use it during its execution. A common way of determining at least substantial subset of the unneeded objects is to determine so called “liveness” of all objects in the heap. An object is defined as “live” if there exists a path of references starting from one of the application variables, and ending at the reference to the given object. A path of references is defined as a sequence of references in which each reference with the exception of the first reference in the sequence is contained within the object identified by the previous reference in the sequence.
  • A frequent problem appearing in object oriented applications written in languages with automatic memory management is that some objects due to the design or coding errors remain live, contrary to the programmer's intentions. Such objects are called lingering objects. Lingering objects tend to accumulate over time, clogging the heap and causing multiple performance problems, eventually leading to the application crash.
  • To detect the lingering objects, programmers in the development phase of the application life-cycle employ memory debugging or memory profiling tools. In one widely practiced debugging methodology, the tool produces a heap dump which serves as a baseline snapshot that illustrates the objects residing in the heap at the given time. A set of test inputs is then run through the program and the tool produces a second snapshot of the heap which illustrates the objects residing in the heap at the second time. The programmer then compares the two snapshots to determine which objects are accumulating over time. By analyzing the reference graphs contained in the heap dumps, and using his/her skills and the knowledge of the program logic, the programmer can determine which objects are lingering, and, what is even more important, why they stay alive. Then the programmer can proceed with fixing the application program in such a way that no more reference paths to the lingering objects can be found by the garbage collector. Despite the acceptance of existing approaches to finding lingering objects, they may be tedious to use, and may not easily scale in a production environment, where heap sizes can be of order of gigabytes.
  • U.S. Patent Publication No. 2004/0181782 discusses a system and method for optimizing memory usage by locating lingering objects. U.S. Pat. No. 6,167,535 discusses object heap analysis techniques for discovering memory leaks and other run time information. U.S. Pat. No. 6,694,507 discusses a method and apparatus for analyzing performance of object oriented programming code. U.S. Pat. No. 6,434,575 discusses a method of instrumenting garbage collection generating a trace file making a single pass analysis of object heap. The disclosures of U.S. Patent Publication No. 2004/0181782, U.S. Pat. No. 6,176,535, U.S. Pat. No. 6,694,507, and U.S. Pat. No. 6,434,575 are hereby incorporated herein in their entirety by reference.
  • Notwithstanding the systems and methods discussed above, there continues to exist a need for methods, systems, and computer program products providing monitoring of object oriented program code memory usage.
  • SUMMARY OF THE INVENTION
  • According to embodiments of the present invention, methods detecting a memory leak may include identifying a largest ChildNode of a ParentNode, and comparing a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode. If the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode, a possible memory leak area may be identified.
  • For example, comparing a total size of the ParentNode to a total size of the largest ChildNode may include calculating a difference between the total size of the ParentNode and the total size of the largest ChildNode. Accordingly, identifying a possible memory leak area may include identifying a possible memory leak area if the difference between the total size of the Parent Node and the total size of the largest ChildNode exceeds a difference threshold.
  • In an alternative, comparing a total size of the ParentNode to a total size of the largest ChildNode may include calculating a ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode. Accordingly, identifying a possible memory leak area may include identifying a possible memory leak area if the ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode is less than a ratio threshold.
  • In addition, if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, a largest GrandChildNode may be identified. After identifying the largest GrandChildNode, a total size of the ChildNode may be compared to a total size of the largest GrandChildNode. If the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, a possible memory leak area may be identified.
  • Moreover, if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode of the ParentNode, the total size of the ChildNode may be compared to a size threshold. If the total size of the ChildNode is less than the size threshold, a no memory leak detected result may be returned. If the total size of the ChildNode is greater than the size threshold, a largest GrandChildNode may be identified. After identifying the largest GrandChildNode, a total size of the ChildNode may be compared to a total size of the largest GrandChildNode, and if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, a possible memory leak area may be identified.
  • If the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, a determination may be made if the largest ChildNode is a terminal node. If the largest ChildNode is a terminal node, a no memory leak detected result may be returned. If the largest ChildNode is not a terminal node, a largest GrandChildNode may be identified. After identifying the largest GrandChildNode, a total size of the ChildNode may be compared to a total size of the largest GrandChildNode. If the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, a possible memory leak area may be identified.
  • If the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, a determination may be made if the largest ChildNode is a terminal node. If the largest ChildNode is a terminal node, a no memory leak detected result may be returned. If the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, the total size of the ChildNode may be compared to a size threshold. If the total size of the ChildNode is less than the size threshold, a no memory leak detected result may be returned. If the ChildNode is not a terminal node and if the total size of the ChildNode is greater than the size threshold, a largest GrandChildNode may be identified. After identifying the largest GrandChildNode, a total size of the ChildNode may be compared to a total size of the largest GrandChildNode. If the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, a possible memory leak area may be identified.
  • According to other embodiments of the present invention, a computer program product may be provided for detecting a memory leak. The computer program product may include a computer readable medium having computer readable program code embodied therein. More particularly, the computer readable program code may include computer readable program code configured to identify a largest ChildNode of a ParentNode, and computer readable program code configured to compare a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode. Additional computer readable program code may be configured to identify a possible memory leak area if the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode.
  • According to still other embodiments of the present invention, a system may be provided for detecting a memory leak. The system may include a processor configured to identify a largest ChildNode of a ParentNode, and to compare a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode. The processor may be further configured to identify a possible memory leak area if the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of data processing systems according to some embodiments of the present invention.
  • FIG. 2 is a more detailed block diagram of systems providing memory leak detection according to some embodiments of the present invention.
  • FIG. 3 is a is a flowchart illustrating operations for detecting memory leaks according to some embodiments of the present invention.
  • FIG. 4 is a is a flowchart illustrating operations for detecting memory leaks according to further embodiments of the present invention.
  • FIG. 5 is a memory tree according to some embodiments of the present invention.
  • DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
  • The invention now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
  • The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
  • Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
  • As will be appreciated by one of skill in the art, the invention may be embodied as methods, data processing systems, and/or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, a transmission media such as those supporting the Internet or an intranet, or magnetic storage devices.
  • Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as JAVA®, Smalltalk or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or in a visually oriented programming environment, such as VisualBasic.
  • The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • The invention is described in part below with reference to flowchart illustrations and/or block diagrams of methods, systems and/or computer program products according to embodiments of the invention: It will be understood that each block of the illustrations, and combinations of blocks, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block or blocks.
  • These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the block or blocks.
  • The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block or blocks.
  • Embodiments of the present invention will now be discussed with respect to FIGS. 1 through 5. As described herein, some embodiments of the present invention provide methods of detecting a memory leak in an object oriented programming language code (such as JAVA® code) memory Heap Dump by identifying a largest ChildNode of a ParentNode in the memory Heap Dump, and comparing a size of the ParentNode to a size of the largest ChildNode of the ParentNode. If the size of the ParentNode is significantly larger than the size of the largest ChildNode, the ParentNode may be identified as a possible memory leak area. Otherwise, a largest GrandChildNode of the ChildNode may be identified, and a size of the ChildNode may be compared to a size of the largest GrandChildNode. If the size of the ChildNode is significantly larger than the size of the largest GrandChildNode, the ChildNode may be identified at a possible memory leak area. The analysis may continue through successive levels of the memory Heap Dump until either an object node is identified as a possible memory leak area, a size of subsequent object node is less than a threshold, or a terminal object node (also referred to as a leaf node) is reached.
  • As used herein, the term Node may refer to a memory object of a memory heap generated by an object oriented programming language such as JAVA®. More generally, the term node may also refer to a file or subdirectory. As used herein, a total size of a node/object may refer to a sum of a size of the node/object and sizes of all children of the node/object (i.e., a sum of a size of the node/object and a size of its sub-tree).
  • Referring now to FIG. 1, a block diagram of data processing systems suitable for use in systems according to some embodiments of the present invention will be discussed. As illustrated in FIG. 1, an exemplary embodiment of a data processing system 30 typically includes input device(s) 32 such as a keyboard or keypad, a display 34, and a memory 36 that communicate with a processor 38. The data processing system 30 may further include a speaker 44, and an I/O data port(s) 46 that also communicates with the processor 38. The I/O data ports 46 can be used to transfer information between the data processing system 30 and another computer system or a network. These components may be conventional components, such as those used in many conventional data processing systems, which may be configured to operate as described herein.
  • FIG. 2 is a block diagram of data processing systems that illustrate systems, methods, and/or computer program products in accordance with embodiments of the present invention. The processor 38 communicates with the memory 36 via an address/data bus 48. The processor 38 can be any commercially available or custom processor, such as a microprocessor. The memory 36 is representative of the overall hierarchy of memory devices containing the software and data used to implement the functionality of the data processing system 30. The memory 36 can include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash memory, SRAM and/or DRAM. Moreover, the processor 38 of FIG. 2 may be coupled to I/O data ports 46, display 34, input devices 32, and/or speaker 44 as discussed above with respect to FIG. 1.
  • As shown in FIG. 2, the memory 36 may include several categories of software and data used in the data processing system 30: an operating system 52; application programs 54; input/output (I/O) device drivers 58; and data 67. As will be appreciated by those of skill in the art, the operating system 52 may be any operating system suitable for use with a data processing system, such as OS/2, AIX or System 390 from International Business Machines Corporation, Armonk, N.Y., Windows95, Windows98, Windows2000 or WindowsXP from Microsoft Corporation, Redmond, Wash., Unix or Linux. The I/O device drivers 58 typically include software routines accessed through the operating system 52 by the application programs 54 to communicate with devices such as the I/O data port(s) 46 and certain memory 36 components. The application programs 54 are illustrative of the programs that implement the various features of the data processing system 30. Finally, the data 67 represents the static and dynamic data used by the application programs 54, the operating system 52, the I/O device drivers 58, and other software programs that may reside in the memory 36.
  • As is further seen in FIG. 2, the application programs 54 may include at least one memory leak detection application 62 which may be provided as a part of and/or in addition to a memory management application 64. As used herein, the term memory leak detection application refers to any application that may provide detection of memory leak areas, for example, in a memory heap dump, such as a JAVA® memory heap dump. Such applications may include, for example, web pages, servlets, applets or the like. In particular embodiments of the present invention, the language independent application may be a JAVA® application. The memory management application 64, for example, may read a memory heap dump 63 file generated by object oriented programming application (such as a JAVA® application), parse each object of the memory heap dump; create graphs defining parent/chile relationships based on the parsed information; and then create memory trees 65 based on the parsed information and the graphs. An example of a memory tree view according to embodiments of the present invention is illustrated in FIG. 5. The memory leak detection application 62 may then analyze the resulting memory tree(s) to locate possible memory leak locations.
  • While embodiments of the present invention are illustrated in FIGS. 1 and 2 with reference to particular divisions between application programs, data and the like, the present invention should not be construed as limited to configurations of FIGS. 1 and 2 but is intended to encompass any configuration capable of carrying out operations described herein.
  • According to embodiments of the present invention, a memory management application 64 may read a memory heap dump 63 file generated by another application program, and the memory heap dump file may include a list of all objects in the memory heap. The memory management application 64 may then parse information for each object of the memory heap dump file and create graphs defining parent/child relationships for objects of the memory heap dump file. The graphs may then be used to generate memory tree(s) 65.
  • An example of a memory tree 65 according to embodiments of the present invention is illustrated in FIG. 5. As shown in FIG. 5, a memory tree may identify a plurality of memory nodes 501 a-x (also referred to as objects) arranged according to parent/child relationships. A ParentNode (also referred to as a parent object) is a node that holds at least one reference to at least one different node, and a child node (also referred to as a child object) is a node for which at least one different node holds a reference. A RootNode (also referred to as a root object) is a node for which no different node holds a reference.
  • In the example of FIG. 5, object 501 a is a RootNode (root object), and node 501 a is also a ParentNode (parentNode) with respect to object 501 b. Object 501 a may also be a ParentNode (parent object) with respect to other ChildNodes not shown in FIG. 5. Node 501 b is a ChildNode with respect to node 501 a and a ParentNode with respect to node 501 c. Node 501 c is a ChildNode with respect to node 501 b and a ParentNode with respect to node 501 d. Node 501 d is a ChildNode with respect to node 501 c and a ParentNode with respect to node 501 e. Node 501 e is a ChildNode with respect to node 501 d and a ParentNode with respect to node 501 f-x. Each of nodes 501 f-x is a ChildNode with respect to node 501 e, and each of nodes 501 f-x may be a ParentNode with respect to one or more nodes not shown in FIG. 5.
  • In the tree view of FIG. 5, the second field for each node identifies a size of that node with a size of an node being defined as an amount of memory that is used to store that node in memory. The first field for each node identifies a total size of the node with the total size being defined as a sum of a size of the node and all child nodes of that node. The third field for each node identifies a number of child nodes of that node, and the fourth field for each node identifies a name address for that node. By way of example, node 501 a has a size of 96, a total size of 115,472,544, and 6 child nodes. Of the six child nodes of node 501 a of FIG. 5, only one child node (node 501 b) is illustrated in FIG. 5. Similarly, node 501 e has a size of 48, a total size of 114,724,256, and 48 child nodes (nodes 501 f-x).
  • Moreover, an node may have more ChildNodes than are illustrated in the tree view of FIG. 5. For example, node 501 a has 6 child nodes of which only ChildNode 501 b is shown; node 501 b has 3 child nodes of which only ChildNode 501 c is shown; and node 501 c has 2 child nodes of which only ChildNode 501 d is shown. In the tree view of FIG. 5, the nodes are sorted by total size with at least the largest ChildNode of each ParentNode being shown. Child nodes of less than a predetermined size may be omitted from the tree view of FIG. 5. While the tree view of FIG. 5 is provided for the sake of illustration, generation of such a tree view is not required according to embodiments of the present invention.
  • According to embodiments of the present invention, a method of detecting a memory leak may include identifying a largest ChildNode of a ParentNode, and comparing a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode. If the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode, the ParentNode may be identified as a possible memory leak area.
  • According to some embodiments, comparing total sizes of the ParentNode to the ChildNode may include calculating a difference between the size of the ParentNode and the size of the largest ChildNode. The ParentNode may be identified as a possible memory leak area if the difference between the size of the Parent Node and the size of the largest ChildNode exceeds a predetermined threshold. In the example of FIG. 5, a threshold difference of 10,000,000 between a ParentNode and a largest ChildNode could be used to determine if the ParentNode should be identified as a possible memory leak area. In alternatives, a threshold difference as low as 1,000,000 or as high as 100,000,000 could be used to determine if the ParentNode should be identified as a possible memory leak area.
  • According to other embodiments of the present invention comparing total sizes of the ParentNode and the ChildNode may include a calculating ratio of the largest ChildNode with respect to the ParentNode. The ParentNode may be identified as a possible memory leak area if the ratio of the largest ChildNode with respect to the ParentNode is less than a ratio threshold. In the example of FIG. 5, ratio threshold of 0.9 (i.e. largest ChildNode/ParentNode<0.9) could be used to determine if the ParentNode should be identified as a possible memory leak area. In alternatives, a ratio threshold as low as 0.1 (i.e. largest ChildNode/ParentNode<0.1) or as high as 0.99 (i.e. largest ChildNode/ParentNode<0.99) could be used to determine if the ParentNode should be identified as a possible memory leak area. As will be understood, an equivalent determination could be made using a ratio of the ParentNode with respect to the largest ChildNode (i.e. ParentNode/largestChildNode), such that the ParentNode is determined as a possible memory leak area if the ParentNode/largestChildNode ratio is greater than a ratio threshold (which is the inverse of the ratio thresholds discussed above, for example, 1.01, 1.11, or 10).
  • The comparisons may begin with a RootNode of a memory heap, such as RootNode 501 a of FIG. 5, and proceed with a largest ChildNode in each successive generation until: (1) a largest Child Node of a next generation has a total size less than a predetermined threshold; (2) a largest ChildNode in a successive generation is a leaf Node (i.e. a terminal node with no ChildNodes); or (3) a ParentNode is identified as a possible memory leak area. Particular embodiments of the present invention will now be discussed in greater detail below with respect to flow charts of FIGS. 3 and 4 with reference to the tree view of FIG. 5.
  • In embodiments of the present invention illustrated in the flow chart of FIG. 3, a RootNode (such as node 501 a of FIG. 5) may be identified as a ParentNode at block 301 in a first iteration, and a largest ChildNode of the ParentNode (such as node 501 b of FIG. 5) may be identified as a comparison node at block 303. At blocks 305 and 307, total sizes of the ParentNode and the comparison node (e.g. the largest ChildNode of the ParentNode) may be compared to determine if the ParentNode should be identified as a possible memory leak area.
  • More particularly, a difference between the total size of the ParentNode and the total size of the comparison node (e.g. the largest ChildNode) may be calculated (e.g. totalsizeParentNode−totalsizeComparisonNode=difference) at block 305. If the difference between the total size of the ParentNode and the total size of the comparison node is greater than a difference threshold at block 307, the ParentNode may be identified as a possible memory leak area at block 309. As discussed above, the difference threshold in the example of FIG. 5 may be a predetermined memory value in the range of 100,000 to 10,000,000 such as 1,000,000. Other difference thresholds, however, may be used depending on the particular application. If the difference is not greater than the difference threshold at block 307, subsequent generations of the memory heap may be tested for possible memory leaks.
  • More particularly, if the ParentNode is not identified as a possible memory leak area, the total size of the comparison node (e.g. the largest ChildNode of the ParentNode) may be compared to a size threshold at block 311. If the total size of the comparison node is less than the size threshold at block 311, further memory leak detection operations may not be warranted, and memory leak operations may thus be terminated. Moreover, a no memory leak detected result may be returned. According to embodiments of the present invention illustrated in FIG. 3, the difference threshold of block 307 and the size threshold of block 311 may be the same or approximately the same because a difference between total sizes of the comparison node and a smaller node cannot exceed the difference threshold if a total size of the comparison node is less than the difference threshold.
  • If the total size of the comparison node is not less than the size threshold at block 311 and the comparison node is not a leaf node (also referred to as a terminal node) at block 315, the comparison node may be identified as a new ParentNode at block 317 and a next iteration of memory leak detection may proceed at blocks 303, 305, and 307 for a next generation of memory objects. In other words, a next iteration of memory leak detection may be performed with respect to the largest ChildNode (the new ParentNode) of the original ParentNode and a GrandChildNode of the original ParentNode. Accordingly, memory leak detection may be performed at each generation of nodes of a memory heap until: a possible memory leak area is identified; a ChildNode having a total size less than size threshold is reached; or a leaf node is reached.
  • With reference to FIGS. 3 and 5, a RootNode (such as node 501 a) may be identified as a ParentNode at block 301, and a largest ChildNode (such as node 501 b) of the ParentNode may be identified as a comparison node at block 303 during a first iteration of memory leak detection. A difference of total sizes of the ParentNode (node 501 a) and the comparison node (node 501 b) may be calculated (e.g. 115,472,544−114,724,600=747,944) at block 305, and the difference (e.g. 747,944) may be compared to a difference threshold (e.g. 1,000,000). With a difference (e.g. 747,944) less than a difference threshold (e.g. 1,000,000) at block 307, the ParentNode (e.g. the RootNode or node 501 a) is not identified as a possible memory leak area. The comparison node (node 501 b) also exceeds the size threshold at block 311, and the comparison node (node 501 b) is not a leaf node at block 315. Accordingly, the comparison node (node 501 b) is identified as a Parent Node for a second iteration of memory leak detection.
  • During the second iteration of memory leak detection, the node 501 b may be identified as the ParentNode, and a largest ChildNode (such as node 501 c) of the ParentNode may be identified as a comparison node at block 303. In other words, a largest ChildNode (node 501 b) and GrandChildNode (node 501 c) of the RootNode (the original ParentNode) may be respectively designated as the ParentNode and comparison node during the second iteration of memory leak detection. A difference of total sizes of the ParentNode (node 501 b) and the comparison node (node 501 c) may be calculated (e.g. 114,724,600−114,724,296=304) at block 305, and the difference (e.g. 304) may be compared to the difference threshold (e.g. 1,000,000). With a difference (e.g. 304) less than the difference threshold (e.g. 1,000,000) at block 307, the ParentNode (e.g. the node 501 b) is not identified as a possible memory leak area. The comparison node (node 501 c) also exceeds the size threshold at block 311, and the comparison node (node 501 c) is not a leaf node at block 315. Accordingly, the comparison node (node 501 c) is identified as a Parent Node for a third iteration of memory leak detection.
  • During the third iteration of memory leak detection, the node 501 c may be identified as the ParentNode, and a largest ChildNode (such as node 501 d) of the ParentNode may be identified as a comparison node at block 303. In other words, a largest ChildNode (node 501 c) and GrandChildNode (node 501 d) of the previous ParentNode (node 501 b) may be respectively designated as the ParentNode and comparison node during the third iteration of memory leak detection. A difference of total sizes of the ParentNode (node 501 c) and the comparison node (node 501 d) may be calculated (e.g. 114,724,296−114,724,256=40) at block 305, and the difference (e.g. 40) may be compared to the difference threshold (e.g. 1,000,000). With a difference (e.g. 40) less than the difference threshold (e.g. 1,000,000) at block 307, the ParentNode (node 501 c) is not identified as a possible memory leak area. The comparison node (node 501 d) also exceeds the size threshold at block 311, and the comparison node (node 501 d) is not a leaf node at block 315. Accordingly, the comparison node (node 501 d) is identified as a Parent Node for a fourth iteration of memory leak detection.
  • During the fourth iteration of memory leak detection, the node 501 d may be identified as the ParentNode, and a largest ChildNode (such as node 501 e) of the ParentNode may be identified as a comparison node at block 303. In other words, a largest ChildNode (node 501 d) and GrandChildNode (node 501 e) of the previous ParentNode (node 501 c) may be respectively designated as the ParentNode and comparison node during the fourth iteration of memory leak detection. A difference of total-sizes of the ParentNode (node 501 d) and the comparison node (node 501 e) may be calculated (e.g. 114,724,256−114,724,208=48) at block 305, and the difference (e.g. 48) may be compared to the difference threshold (e.g. 1,000,000). With a difference (e.g. 48) less than the difference threshold (e.g. 1,000,000) at block 307, the ParentNode (node 501 d) is not identified as a possible memory leak area. The comparison node (node 501 e) also exceeds the size threshold at block 311, and the comparison node (node 501 e) is not a leaf node at block 315. Accordingly, the comparison node (node 501 e) is identified as a Parent Node for a fifth iteration of memory leak detection.
  • During the fifth iteration of memory leak detection, the node 501 e may be identified as the ParentNode, and a largest ChildNode (such as node 501 f) of the ParentNode may be identified as a comparison node at block 303. In other words, a largest ChildNode (node 501 e) and GrandChildNode (node 501 f) of the previous ParentNode (node 501 d) may be respectively designated as the ParentNode and comparison node during the fifth iteration of memory leak detection. A difference of total sizes of the ParentNode (node 501 e) and the comparison node (node 501 f) may be calculated (e.g. 114,724,208−1,626,704=113,097,504) at block 305, and the difference (e.g. 113,097,504) may be compared to the difference threshold (e.g. 1,000,000). With a difference (e.g. 113,097,504) greater than the difference threshold (e.g. 1,000,000) at block 307, the ParentNode (node 501 e) may be identified as a possible memory leak area. Memory leak detection operations may then be terminated with the result that node 501 e is identified as a possible memory leak area.
  • In additional embodiments of the present invention, multiple largest ChildNodes of the ParentNode may be identified as ComparisonNodes at block 303. More particularly, each ChildNode having a total size greater than a size threshold may be identified as a Comparison Node. At block 307, a difference between a total size of each ComparisonNode and a total size of the ParentNode may be compared with the difference threshold. If a difference between a total size of any of the ComparisonNodes and the Parent Node is greater than the difference threshold, the ParentNode may be identified as a possible memory leak area at block 309. If none of differences exceed the difference threshold at block 307, then each of the ComparisonNodes may be compared to the threshold of block 311 and a determination may be made if any of the ComparisonNodes is a leaf node at block 315. A plurality of ComparisonNodes may thus be identified as ParentNodes at block 317, and operations of blocks 303, 305, and 307 may thus be performed with respect to a plurality of ComparisonNodes of the previous iteration.
  • Accordingly, memory leak detection operations may proceed in serial and/or parallel with respect to multiple ChildNodes at one or more generations of a memory heap dump. Moreover, operations of block 311 may be omitted if a suitable size threshold is used to identify ComparisonNodes at block 303.
  • In embodiments of the present invention illustrated in the flow chart of FIG. 4, a RootNode (such as node 501 a of FIG. 5) may be identified as a ParentNode at block 401 in a first iteration, and a largest ChildNode of the ParentNode (such as node 501 b of FIG. 5) may be identified as a comparison node at block 403. At blocks 405 and 407, total sizes of the ParentNode and the comparison node (e.g. the largest ChildNode of the ParentNode) may be compared to determine if the ParentNode should be identified as a possible memory leak area.
  • More particularly, a ratio of the total sizes of the ParentNode and the comparison node (e.g. the largest ChildNode) may be calculated (e.g. totalsizeParentNode/totalsizeComparisonNode=ratio) at block 405. If the ratio of the total sizes of the ParentNode and the comparison node is less than a ratio threshold at block 407, the ParentNode may be identified as a possible memory leak area at block 409. As discussed above, the ratio threshold in the example of FIG. 5 may be a predetermined ratio value in the range of 0.1 to 0.99 such as 0.9. Other ratio thresholds, however, may be used depending on the particular application. If the ratio is not greater than the ratio threshold at block 407, subsequent generations of the memory heap may be tested for possible memory leaks.
  • More particularly, if the ParentNode is not identified as a possible memory leak area, the total size of the comparison node (e.g. the largest ChildNode of the ParentNode) may be compared to a size threshold at block 411. By way of example, the size threshold may be a predetermined threshold in the range of 100,000 to 10,000,000. If the total size of the comparison node is less than the size threshold at block 411, further memory leak detection operations may not be warranted, and memory leak operations may thus be terminated. Moreover, a no memory leak detected result may be returned.
  • If the total size of the comparison node is not less than the size threshold at block 411 and the comparison node is not a leaf node (also referred to as a terminal node) at block 415, the comparison node may be identified as a new ParentNode at block 417 and a next iteration of memory leak detection may proceed at blocks 403, 405, and 407 for a next generation of memory objects. In other words, a next iteration of memory leak detection may be performed with respect to the largest ChildNode (the new ParentNode) of the original ParentNode and a GrandChildNode of the original ParentNode. Accordingly, memory leak detection may be performed at each generation of nodes of a memory heap until: a possible memory leak area is identified; a ChildNode having a total size less than size threshold is reached; or a leaf node is reached.
  • With reference to FIGS. 4 and 5, a RootNode (such as node 501 a) may be identified as a ParentNode at block 401, and a largest ChildNode (such as node 501 b) of the ParentNode may be identified as a comparison node at block 403 during a first iteration of memory leak detection. A ratio of total sizes of the comparison node (node 501 b) with respect to the ParentNode (node 501 a) may be calculated (e.g. 114,724,600÷115,472,544=0.999) at block 405, and the ratio (e.g. 0.999) may be compared to a ratio threshold (e.g. 0.90). With a ratio (e.g. 0.999) greater than a ratio threshold (e.g. 0.90) at block 407, the ParentNode (e.g. the RootNode or node 501 a) is not identified as a possible memory leak area. The comparison node (node 501 b) also exceeds the size threshold at block 411, and the comparison node (node 501 b) is not a leaf node at block 415. Accordingly, the comparison node (node 501 b) is identified as a ParentNode for a second iteration of memory leak detection.
  • During the second iteration of memory leak detection, the node 501 b may be identified as the ParentNode, and a largest ChildNode (such as node 501 c) of the ParentNode may be identified as a comparison node at block 403. In other words, a largest ChildNode (node 501 b) and GrandChildNode (node 501 c) of the RootNode (the original ParentNode) may be respectively designated as the ParentNode and comparison node during the second iteration of memory leak detection. A ratio of total sizes of the comparison node (node 501 c) with respect to the ParentNode (node 501 b) may be calculated (e.g. 114,724,296÷114,724,600=0.999) at block 405, and the ratio (e.g. 0.999) may be compared to the ratio threshold (e.g. 0.90). With a ratio (e.g. 0.999) greater than the ratio threshold (e.g. 0.90) at block 407, the ParentNode (e.g. the node 501 b) is not identified as a possible memory leak area. The comparison node (node 501 c) also exceeds the size threshold at block 411, and the comparison node (node 501 c) is not a leaf node at block 415. Accordingly, the comparison node (node 501 c) is identified as a Parent Node for a third iteration of memory leak detection.
  • During the third iteration of memory leak detection, the node 501 c may be identified as the ParentNode, and a largest ChildNode (such as node 501 d) of the ParentNode may be identified as a comparison node at block 403. In other words, a largest ChildNode (node 501 c) and GrandChildNode (node 501 d) of the previous ParentNode (node 501 b) may be respectively designated as the ParentNode and comparison node during the third iteration of memory leak detection. A ratio of total sizes of the comparison node (node 501 d) with respect to the Parent Node (node 501 c) may be calculated (e.g. 114,724,256÷114,724,296=0.999) at block 405, and the ratio (e.g. 0.999) may be compared to the ratio threshold (e.g. 0.90). With a ratio (e.g. 0.999) greater than the ratio threshold (e.g. 0.90) at block 407, the ParentNode (node 501 c) is not identified as a possible memory leak area. The comparison node (node 501 d) also exceeds the size threshold at block 411, and the comparison node (node 501 d) is not a leaf node at block 415. Accordingly, the comparison node (node 501 d) is identified as a Parent Node for a fourth iteration of memory leak detection.
  • During the fourth iteration of memory leak detection, the node 501 d may be identified as the ParentNode, and a largest ChildNode (such as node 501 e) of the ParentNode may be identified as a comparison node at block 403. In other words, a largest ChildNode (node 501 d) and Grand-ChildNode (node 501 e) of the previous ParentNode (node 501 c) may be respectively designated as the ParentNode and comparison node during the fourth iteration of memory leak detection. A ratio of total sizes of the comparison node (node 501 e) with respect to the ParentNode (node 501 d) may be calculated (e.g. 114,724,208÷114,724,256=0.999) at block 405, and the ratio (e.g. 0.999) may be compared to the ratio threshold (e.g. 0.90). With a ratio (e.g. 0.999) greater than the ratio threshold (e.g. 0.90) at block 407, the ParentNode (node 501 d) is not identified as a possible memory leak area. The comparison node (node 501 e) also exceeds the size threshold at block 411, and the comparison node (node 501 e) is not a leaf node at block 415. Accordingly, the comparison node (node 501 e) is identified as a Parent Node for a fifth iteration of memory leak detection.
  • During the fifth iteration of memory leak detection, the node 501 e may be identified as the ParentNode, and a largest ChildNode (such as node 501 f) of the ParentNode may be identified as a comparison node at block 403. In other words, a largest ChildNode (node 501 e) and GrandChildNode (node 501 f) of the previous ParentNode (node 501 d) may be respectively designated as the ParentNode and comparison node during the fifth iteration of memory leak detection. A ratio of total sizes of the comparison node (node 501 f) with respect to the ParentNode (node 501 e) may be calculated (e.g. 1,626,704÷114,724,208=0.014) at block 405, and the ratio (e.g. 0.014) may be compared to the ratio threshold (e.g. 0.90). With a ratio (e.g. 0.014) less than the ratio threshold (e.g. 0.90) at block 407, the ParentNode (node 501 e) may be identified as a possible memory leak area at block 409. Memory leak detection operations may then be terminated with the result that node 501 e is identified as a possible memory leak area.
  • In additional embodiments of the present invention, multiple largest ChildNodes of the ParentNode may be identified as ComparisonNodes at block 403. More particularly, each ChildNode having a total size greater than a size threshold may be identified as a Comparison Node. At block 407, a ratio of a total size of each ComparisonNode with respect to a total size of the ParentNode may be compared with the ratio threshold. If a ratio of a total size of any of the ComparisonNodes with respect to the Parent Node is greater than the ratio threshold, the ParentNode may be identified as a possible memory leak area at block 409. If none of ratios exceed the ratio threshold at block 407, then each of the ComparisonNodes may be compared to the threshold of block 411 and a determination may be made if any of the ComparisonNodes is a leaf node at block 415. A plurality of ComparisonNodes may thus be identified as ParentNodes at block 417 for a next iteration, and operations of blocks 403, 405, and 407 may thus be performed with respect to a plurality of ComparisonNodes of the previous iteration.
  • Accordingly, memory leak detection operations may proceed in serial and/or parallel with respect to multiple ChildNodes at one or more generations of a memory heap dump. Moreover, operations of block 411 may be omitted if a suitable size threshold is used to identify ComparisonNodes at block 403.
  • Many alterations and modifications may be made by those having ordinary skill in the art, given the benefit of present disclosure, without departing from the spirit and scope of the invention. Therefore, it must be understood that the illustrated embodiments have been set forth only for the purposes of example, and that it should not be taken as limiting the invention as defined by the following claims. The following claims are, therefore, to be read to include not only the combination of elements which are literally set forth but all equivalent elements for performing substantially the same function in substantially the same way to obtain substantially the same result. The claims are thus to be understood to include what is specifically illustrated and described above, what is conceptually equivalent, and also what incorporates the essential idea of the invention.

Claims (20)

1. A method of detecting a memory leak, the method comprising:
identifying a largest ChildNode of a ParentNode;
comparing a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode; and
if the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode, identifying a possible memory leak area.
2. A method according to claim 1 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a difference between the total size of the ParentNode and the total size of the largest ChildNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area if the difference between the total size of the Parent Node and the total size of the largest ChildNode exceeds a difference threshold.
3. A method according to claim 1 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area if the ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode is less than a ratio threshold.
4. A method according to claim 1 further comprising:
if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, identifying a largest GrandChildNode;
after identifying the largest GrandChildNode, comparing a total size of the ChildNode to a total size of the largest GrandChildNode; and
if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, identifying a possible memory leak area.
5. A method according to claim 1 further comprising:
if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode of the ParentNode, comparing the total size of the ChildNode to a size threshold;
if the total size of the ChildNode is less than the size threshold, returning a no memory leak detected result;
if the total size of the ChildNode is greater than the size threshold, identifying a largest GrandChildNode;
after identifying the largest GrandChildNode, comparing a total size of the ChildNode to a total size of the largest GrandChildNode; and
if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, identifying a possible memory leak area.
6. A method according to claim 1 further comprising:
if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, determining if the largest ChildNode is a terminal node;
if the largest ChildNode is a terminal node, returning a no memory leak detected result;
if the largest ChildNode is not a terminal node, identifying a largest GrandChildNode;
after identifying the largest GrandChildNode, comparing a total size of the ChildNode to a total size of the largest GrandChildNode; and
if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, identifying a possible memory leak area.
7. A method according to claim 1 further comprising:
if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, determining if the largest ChildNode is a terminal node;
if the largest ChildNode is a terminal node, returning a no memory leak detected result;
if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, comparing the total size of the ChildNode to a size threshold;
if the total size of the ChildNode is less than the size threshold, returning a no memory leak detected result;
if the ChildNode is not a terminal node and if the total size of the ChildNode is greater than the size threshold, identifying a largest GrandChildNode;
after identifying the largest GrandChildNode, comparing a total size of the ChildNode to a total size of the largest GrandChildNode; and
if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode, identifying a possible memory leak area.
8. A computer program product for detecting a memory leak, the computer program product comprising a computer readable medium having computer readable program code embodied therein, the computer readable program code comprising:
computer readable program code configured to identify a largest ChildNode of a ParentNode;
computer readable program code configured to compare a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode; and
computer readable program code configured to identify a possible memory leak area when the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode.
9. A computer program product according to claim 8 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a difference between the total size of the ParentNode and the total size of the largest ChildNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area when the difference between the total size of the Parent Node and the total size of the largest ChildNode exceeds a difference threshold.
10. A computer program product according to claim 8 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area when the ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode is less than a ratio threshold.
11. A computer program product according to claim 8 further comprising:
computer readable program code configured to identify a largest GrandChildNode when the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode;
computer readable program code configured to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode; and
computer readable program code configured to identify a possible memory leak area when the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
12. A computer program product according to claim 8 further comprising:
computer readable program code configured to compare the total size of the ChildNode to a size threshold when the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode of the ParentNode;
computer readable program code configured to return a no memory leak detected result when the total size of the ChildNode is less than the size threshold;
computer readable program code configured to identify a largest GrandChildNode when the total size of the ChildNode is greater than the size threshold;
computer readable program code configured to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode of the ChildNode; and
computer readable program code configured to identify a possible memory leak area when the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
13. A computer program product according to claim 8 further comprising:
computer readable program code configured to determine if the largest ChildNode is a terminal node when the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode;
computer readable program code configured to return a no memory leak detected result when the largest ChildNode is a terminal node;
computer readable program code configured to identify a largest GrandChildNode when the largest ChildNode is not a terminal node;
computer readable program code configured to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode; and
computer readable program code configured to identify a possible memory leak area when the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
14. A computer program product according to claim 8 further comprising:
computer readable program code configured to determine if the largest ChildNode is a terminal node when the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode;
computer readable program code configured to return a no memory leak detected result when the largest ChildNode is a terminal node;
computer readable program code configured to compare the total size of the ChildNode to a size threshold when the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode;
computer readable program code configured to return a no memory leak detected result when the total size of the ChildNode is less than the size threshold;
computer readable program code configured to identify a largest GrandChildNode when the ChildNode is not a terminal node and when the total size of the ChildNode is greater than the size threshold;
computer readable program code configured to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode; and
computer readable program code configured to identify a possible memory leak area when the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
15. A system for detecting a memory leak, the system comprising:
a processor configured to identify a largest ChildNode of a ParentNode, to compare a total size of the ParentNode to a total size of the largest ChildNode of the ParentNode, and to identify a possible memory leak area if the total size of the ParentNode is significantly larger than the total size of the largest ChildNode of the ParentNode.
16. A system according to claim 15 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a difference between the total size of the ParentNode and the total size of the largest ChildNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area if the difference between the total size of the Parent Node and the total size of the largest ChildNode exceeds a difference threshold.
17. A system according to claim 15 wherein comparing a total size of the ParentNode to a total size of the largest ChildNode comprises calculating a ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode, and wherein identifying a possible memory leak area comprises identifying a possible memory leak area if the ratio of the total size of the largest ChildNode with respect to the total size of the ParentNode is less than a ratio threshold.
18. A system according to claim 15 wherein the processor is further configured to identify a largest GrandChildNode if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode, and to identify a possible memory leak area if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
19. A system according to claim 15 wherein the processor is further configured to compare the total size of the ChildNode to a size threshold if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode of the ParentNode, to return a no memory leak detected result if the total size of the ChildNode is less than the size threshold, to identify a largest GrandChildNode if the total size of the ChildNode is greater than the size threshold, to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode, and to identify a possible memory leak area if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
20. A system according to claim 15 wherein the processor is further configured to determine if the largest ChildNode is a terminal node if the total size of the ParentNode is not significantly larger than the total size of the largest ChildNode, to return a no memory leak detected result if the largest ChildNode is a terminal node, to identify a largest GrandChildNode of the ChildNode if the largest ChildNode is not a terminal node, to compare a total size of the ChildNode to a total size of the largest GrandChildNode after identifying the largest GrandChildNode, and to identify a possible memory leak area if the total size of the ChildNode is significantly larger than the total size of the largest GrandChildNode.
US11/081,910 2005-03-16 2005-03-16 Methods, systems and computer program products for detecting memory leaks Abandoned US20060212852A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/081,910 US20060212852A1 (en) 2005-03-16 2005-03-16 Methods, systems and computer program products for detecting memory leaks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/081,910 US20060212852A1 (en) 2005-03-16 2005-03-16 Methods, systems and computer program products for detecting memory leaks
US12/147,139 US8195720B2 (en) 2005-03-16 2008-06-26 Detecting memory leaks

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/147,139 Continuation US8195720B2 (en) 2005-03-16 2008-06-26 Detecting memory leaks

Publications (1)

Publication Number Publication Date
US20060212852A1 true US20060212852A1 (en) 2006-09-21

Family

ID=37011832

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/081,910 Abandoned US20060212852A1 (en) 2005-03-16 2005-03-16 Methods, systems and computer program products for detecting memory leaks
US12/147,139 Expired - Fee Related US8195720B2 (en) 2005-03-16 2008-06-26 Detecting memory leaks

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/147,139 Expired - Fee Related US8195720B2 (en) 2005-03-16 2008-06-26 Detecting memory leaks

Country Status (1)

Country Link
US (2) US20060212852A1 (en)

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070255775A1 (en) * 2006-04-28 2007-11-01 Sap Ag Method and system for inspecting memory leaks
US20080162547A1 (en) * 2006-12-29 2008-07-03 Sap Ag System and method for measuring memory consumption differences between objects within an object-oriented programming environment
US20080163124A1 (en) * 2006-12-29 2008-07-03 Sap Ag Graphical user interface system and method for presenting objects
US20080178189A1 (en) * 2007-01-23 2008-07-24 Piotr Findeisen Efficient detection of sources of increasing memory consumption
US20090228870A1 (en) * 2008-03-06 2009-09-10 International Business Machines Corporation On-demand monitoring of memory usage
US20090259994A1 (en) * 2008-04-15 2009-10-15 Nokia Corporation Apparatus, Method, and Computer Program Product for Analyzing Program Memory Operations
US20090295814A1 (en) * 2008-05-29 2009-12-03 Tetsuya Matsusaka Operation displaying device and image forming device
GB2464179A (en) * 2008-10-09 2010-04-14 Ibm Identifying the source of a memory leak by grouping repeated patterns of the same object type
US20110083180A1 (en) * 2009-10-01 2011-04-07 Kaspersky Lab, Zao Method and system for detection of previously unknown malware
US20110161956A1 (en) * 2009-12-31 2011-06-30 International Business Machines Corporation Heap dump object identification in a heap dump analysis tool
US7996615B2 (en) 2004-12-28 2011-08-09 Sap Ag Cache region concept
US20120266028A1 (en) * 2011-04-13 2012-10-18 Hon Hai Precision Industry Co., Ltd. Electronic device and method for debugging programs
US20130007404A1 (en) * 2011-06-30 2013-01-03 David Hugh Malcolm Using heuristics for field types of a structure to categorize dynamic memory allocations
US20130007400A1 (en) * 2011-06-30 2013-01-03 David Hugh Malcolm Using symbol information for categorization of dynamic memory allocations
US20140189650A1 (en) * 2013-05-21 2014-07-03 Concurix Corporation Setting Breakpoints Using an Interactive Graph Representing an Application
US8799359B2 (en) 2004-12-28 2014-08-05 Sap Ag Session management within a multi-tiered enterprise network
US9311082B2 (en) 2006-12-29 2016-04-12 Sap Se System and method for processing graph objects
US9432240B2 (en) 2005-04-29 2016-08-30 Sap Se Flexible failover configuration
US9658943B2 (en) 2013-05-21 2017-05-23 Microsoft Technology Licensing, Llc Interactive graph for navigating application code
CN106708616A (en) * 2016-11-29 2017-05-24 深圳天珑无线科技有限公司 Process control method and process control device
US9734040B2 (en) 2013-05-21 2017-08-15 Microsoft Technology Licensing, Llc Animated highlights in a graph representing an application
US9754396B2 (en) 2013-07-24 2017-09-05 Microsoft Technology Licensing, Llc Event chain visualization of performance data
CN107360317A (en) * 2017-06-29 2017-11-17 努比亚技术有限公司 The detection method and mobile terminal, storage medium of application resource leakage
US9864672B2 (en) 2013-09-04 2018-01-09 Microsoft Technology Licensing, Llc Module specific tracing in a shared module environment
US10346292B2 (en) 2013-11-13 2019-07-09 Microsoft Technology Licensing, Llc Software component recommendation based on multiple trace runs

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101639804A (en) * 2008-07-29 2010-02-03 国际商业机器公司 Method for confirming memory leakage position in program and device
US9164872B2 (en) 2013-05-22 2015-10-20 Sap Se Tracking of program objects during request processing

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5487166A (en) * 1994-09-19 1996-01-23 Amdahl Corporation Computer with two-dimensional merge tournament sort using offset-value coding
US5555405A (en) * 1993-07-06 1996-09-10 Digital Equipment Corporation Method and apparatus for free space management in a forwarding database having forwarding entry sets and multiple free space segment queues
US6167535A (en) * 1997-12-09 2000-12-26 Sun Microsystems, Inc. Object heap analysis techniques for discovering memory leaks and other run-time information
US6434575B1 (en) * 1998-11-12 2002-08-13 International Business Machines Corporation Method of instrumenting garbage collection generating a trace file making a single pass analysis of object heap
US6694507B2 (en) * 2000-12-15 2004-02-17 International Business Machines Corporation Method and apparatus for analyzing performance of object oriented programming code
US6694323B2 (en) * 2002-04-25 2004-02-17 Sybase, Inc. System and methodology for providing compact B-Tree
US20040181782A1 (en) * 2003-03-13 2004-09-16 Piotr Findeisen System and method for optimizing memory usage by locating lingering objects

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987469A (en) * 1996-05-14 1999-11-16 Micro Logic Corp. Method and apparatus for graphically representing information stored in electronic media
US5822593A (en) * 1996-12-06 1998-10-13 Xerox Corporation High-level loop fusion
US5949911A (en) * 1997-05-16 1999-09-07 Teralogic, Inc. System and method for scalable coding of sparse data sets
US6560773B1 (en) * 1997-12-12 2003-05-06 International Business Machines Corporation Method and system for memory leak detection in an object-oriented environment during real-time trace processing
KR100611995B1 (en) * 1998-07-07 2006-08-11 삼성전자주식회사 Method for determining maximum hop count in bus with tree structure
US6556983B1 (en) * 2000-01-12 2003-04-29 Microsoft Corporation Methods and apparatus for finding semantic information, such as usage logs, similar to a query using a pattern lattice data space
US6829222B2 (en) * 2000-04-25 2004-12-07 Board Of Regents The University Of Texas System Clusterhead selection in wireless ad hoc networks
US6931615B1 (en) * 2002-06-04 2005-08-16 Cadence Design Systems, Inc. Method and apparatus for identifying a path between source and target states
US7234080B2 (en) * 2002-10-18 2007-06-19 Computer Associates Think, Inc. Locating potential sources of memory leaks
US20040181562A1 (en) * 2003-03-13 2004-09-16 Piotr Findeisen System and method for determining deallocatable memory in a heap
US7509344B1 (en) * 2003-08-18 2009-03-24 Google Inc. Method for detecting link spam in hyperlinked databases
US7487308B1 (en) * 2003-11-28 2009-02-03 Symantec Operating Corporation Identification for reservation of replacement storage devices for a logical volume to satisfy its intent
US20090106289A1 (en) * 2004-10-01 2009-04-23 Turbo Data Laboratories Inc. Array Generation Method And Array Generation Program
US8359450B2 (en) * 2009-02-13 2013-01-22 Opnet Technologies, Inc. Memory utilization analysis

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555405A (en) * 1993-07-06 1996-09-10 Digital Equipment Corporation Method and apparatus for free space management in a forwarding database having forwarding entry sets and multiple free space segment queues
US5487166A (en) * 1994-09-19 1996-01-23 Amdahl Corporation Computer with two-dimensional merge tournament sort using offset-value coding
US6167535A (en) * 1997-12-09 2000-12-26 Sun Microsystems, Inc. Object heap analysis techniques for discovering memory leaks and other run-time information
US6434575B1 (en) * 1998-11-12 2002-08-13 International Business Machines Corporation Method of instrumenting garbage collection generating a trace file making a single pass analysis of object heap
US6694507B2 (en) * 2000-12-15 2004-02-17 International Business Machines Corporation Method and apparatus for analyzing performance of object oriented programming code
US6694323B2 (en) * 2002-04-25 2004-02-17 Sybase, Inc. System and methodology for providing compact B-Tree
US20040181782A1 (en) * 2003-03-13 2004-09-16 Piotr Findeisen System and method for optimizing memory usage by locating lingering objects

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10007608B2 (en) 2004-12-28 2018-06-26 Sap Se Cache region concept
US9009409B2 (en) 2004-12-28 2015-04-14 Sap Se Cache region concept
US7996615B2 (en) 2004-12-28 2011-08-09 Sap Ag Cache region concept
US8799359B2 (en) 2004-12-28 2014-08-05 Sap Ag Session management within a multi-tiered enterprise network
US9432240B2 (en) 2005-04-29 2016-08-30 Sap Se Flexible failover configuration
US8229979B2 (en) * 2006-04-28 2012-07-24 Sap Ag Method and system for inspecting memory leaks
US20070255775A1 (en) * 2006-04-28 2007-11-01 Sap Ag Method and system for inspecting memory leaks
US20080162547A1 (en) * 2006-12-29 2008-07-03 Sap Ag System and method for measuring memory consumption differences between objects within an object-oriented programming environment
US9311082B2 (en) 2006-12-29 2016-04-12 Sap Se System and method for processing graph objects
US7725505B2 (en) * 2006-12-29 2010-05-25 Sap Ag System and method for measuring memory consumption differences between objects within an object-oriented programming environment
US20080163124A1 (en) * 2006-12-29 2008-07-03 Sap Ag Graphical user interface system and method for presenting objects
US8640086B2 (en) 2006-12-29 2014-01-28 Sap Ag Graphical user interface system and method for presenting objects
US20080178189A1 (en) * 2007-01-23 2008-07-24 Piotr Findeisen Efficient detection of sources of increasing memory consumption
US8037477B2 (en) * 2007-01-23 2011-10-11 Hewlett-Packard Development Company, L.P. Efficient detection of sources of increasing memory consumption
US20090228870A1 (en) * 2008-03-06 2009-09-10 International Business Machines Corporation On-demand monitoring of memory usage
US8904359B2 (en) * 2008-03-06 2014-12-02 International Business Machines Corporation On-demand monitoring of memory usage
US20090259994A1 (en) * 2008-04-15 2009-10-15 Nokia Corporation Apparatus, Method, and Computer Program Product for Analyzing Program Memory Operations
US8334875B2 (en) * 2008-05-29 2012-12-18 Kyocera Document Solutions Inc. Operation displaying device and image forming device
US20090295814A1 (en) * 2008-05-29 2009-12-03 Tetsuya Matsusaka Operation displaying device and image forming device
GB2464179A (en) * 2008-10-09 2010-04-14 Ibm Identifying the source of a memory leak by grouping repeated patterns of the same object type
US20110083180A1 (en) * 2009-10-01 2011-04-07 Kaspersky Lab, Zao Method and system for detection of previously unknown malware
US8572740B2 (en) * 2009-10-01 2013-10-29 Kaspersky Lab, Zao Method and system for detection of previously unknown malware
US9459991B2 (en) * 2009-12-31 2016-10-04 International Business Machines Corporation Heap dump object identification in a heap dump analysis tool
US20110161956A1 (en) * 2009-12-31 2011-06-30 International Business Machines Corporation Heap dump object identification in a heap dump analysis tool
US20120266028A1 (en) * 2011-04-13 2012-10-18 Hon Hai Precision Industry Co., Ltd. Electronic device and method for debugging programs
US8370815B2 (en) * 2011-04-13 2013-02-05 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. Electronic device and method for debugging programs
US8719539B2 (en) * 2011-06-30 2014-05-06 Red Hat, Inc. Using heuristics for field types of a structure to categorize dynamic memory allocations
US20130007400A1 (en) * 2011-06-30 2013-01-03 David Hugh Malcolm Using symbol information for categorization of dynamic memory allocations
US20130007404A1 (en) * 2011-06-30 2013-01-03 David Hugh Malcolm Using heuristics for field types of a structure to categorize dynamic memory allocations
US8725978B2 (en) * 2011-06-30 2014-05-13 Red Hat, Inc. Using symbol information for categorization of dynamic memory allocations
US9734040B2 (en) 2013-05-21 2017-08-15 Microsoft Technology Licensing, Llc Animated highlights in a graph representing an application
US20140189650A1 (en) * 2013-05-21 2014-07-03 Concurix Corporation Setting Breakpoints Using an Interactive Graph Representing an Application
US9658943B2 (en) 2013-05-21 2017-05-23 Microsoft Technology Licensing, Llc Interactive graph for navigating application code
US9754396B2 (en) 2013-07-24 2017-09-05 Microsoft Technology Licensing, Llc Event chain visualization of performance data
US9864672B2 (en) 2013-09-04 2018-01-09 Microsoft Technology Licensing, Llc Module specific tracing in a shared module environment
US10346292B2 (en) 2013-11-13 2019-07-09 Microsoft Technology Licensing, Llc Software component recommendation based on multiple trace runs
CN106708616A (en) * 2016-11-29 2017-05-24 深圳天珑无线科技有限公司 Process control method and process control device
CN107360317A (en) * 2017-06-29 2017-11-17 努比亚技术有限公司 The detection method and mobile terminal, storage medium of application resource leakage

Also Published As

Publication number Publication date
US20080320449A1 (en) 2008-12-25
US8195720B2 (en) 2012-06-05

Similar Documents

Publication Publication Date Title
Tan et al. Bug characteristics in open source software
US9208057B2 (en) Efficient model checking technique for finding software defects
Lo et al. SMArTIC: towards building an accurate, robust and scalable specification miner
Nistor et al. Toddler: Detecting performance problems via similar memory-access patterns
Ramanathan et al. Path-sensitive inference of function precedence protocols
Gyimóthy et al. An efficient relevant slicing method for debugging
Binkley The application of program slicing to regression testing
US7844951B2 (en) Specification generation from implementations
Sridharan et al. Thin slicing
US8732673B2 (en) Automated debugging system and method
Ernst et al. Quickly detecting relevant program invariants
Mitchell et al. Leakbot: An automated and lightweight tool for diagnosing memory leaks in large Java applications
US7853930B2 (en) Annotating graphs to allow quick loading and analysis of very large graphs
Prete et al. Template-based reconstruction of complex refactorings
Kwon et al. Mantis: Automatic performance prediction for smartphone applications
Ramanathan et al. Static specification inference using predicate mining
Raza et al. Bauhaus–a tool suite for program analysis and reverse engineering
Sahoo et al. Using likely invariants for automated software fault localization
US6651243B1 (en) Method and system for periodic trace sampling for real-time generation of segments of call stack trees
Csallner et al. Check'n'crash: combining static checking and testing
Verbeek et al. Verifying workflows with cancellation regions and or-joins: An approach based on relaxed soundness and invariants
Jin et al. Automated behavioral regression testing
Xiao et al. Precise identification of problems for structural test generation
Hanam et al. Discovering bug patterns in JavaScript
Xu et al. Precise memory leak detection for java software using container profiling

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HWANG, JINWOO;REEL/FRAME:016509/0994

Effective date: 20050315

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION