[go: up one dir, main page]

WO1993003435A1 - Procede et appareil destine a identifier des fuites de memoire et a rechercher des pointeurs dans un programme informatique - Google Patents

Procede et appareil destine a identifier des fuites de memoire et a rechercher des pointeurs dans un programme informatique Download PDF

Info

Publication number
WO1993003435A1
WO1993003435A1 PCT/US1992/006419 US9206419W WO9303435A1 WO 1993003435 A1 WO1993003435 A1 WO 1993003435A1 US 9206419 W US9206419 W US 9206419W WO 9303435 A1 WO9303435 A1 WO 9303435A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
memory
allocated
pointer
blocks
Prior art date
Application number
PCT/US1992/006419
Other languages
English (en)
Inventor
Reed Hastings
John Dawes
Original Assignee
Pure Software, Inc.
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 Pure Software, Inc. filed Critical Pure Software, Inc.
Publication of WO1993003435A1 publication Critical patent/WO1993003435A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/362—Debugging of software
    • G06F11/366—Debugging of software using diagnostics
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment

Definitions

  • the present invention relates generally to a method and apparatus for analyzing and debugging memory usage by a computer program.
  • the present invention relates to a debugging tool for identifying pointers and memory leaks in a computer program.
  • 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.
  • 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.
  • 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.
  • pan-system memory leaks 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a marking procedure basically the same as the "mark” part of "mark-and-sweep" is performed.
  • 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.
  • 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.
  • 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
  • Fig. 9 is a flowchart for the mark_block routine 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.
  • 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.
  • 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.
  • 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 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.
  • 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 memory allocation function malloc takes one argument, N, the number of bytes needed by the program.
  • N the number of bytes needed by the program.
  • the operation of the preferred embodiment's modified malloc routine is illustrated in Fig. 5.
  • a block of memory large enough for the MallocHeader and the user's N bytes is allocated.
  • 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.
  • 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.
  • the frame pointer chain is followed, and each saved return address is stored into the MallocHeader.
  • pointer 30 of Fig. 2 is returned to the user's N bytes.
  • Fig. 6 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.
  • 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.
  • 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.
  • a function findleaks is supplied, which works as illustrated in Fig. 7.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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) .
  • 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.
  • State 500 includes most program operations.
  • state 510 is entered, in which memory for a labelled block is allocated.
  • 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.
  • free 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Bibliothèque de programmes spécialisés (3), dont certains programmes mettent en ÷uvre l'interface malloc (110, 120, 130, 140). Les programmes à interface malloc étiquettent également chaque bloc attribué à l'aide de plusieurs éléments d'information, y compris une chaîne d'appels partielle commençant par l'appelant de malloc. D'autres programmes utilisent l'information présente dans l'étiquette pour rechercher des pointeurs et des fuites de mémoire, de manière à aider un programmeur à mettre au point un programme. Dans sa forme la plus simple, le procédé de recherche des fuites de mémoire consiste à associer des blocs attribués à des chaînes d'appel partielles (510), à marquer les blocs attribués à l'aide de chaînes d'appel partielles (520), à marquer les blocs attribués accessibles (560), à rechercher dans la mémoire les blocs attribués non marqués (570) et à communiquer les chaînes d'appel partielles de blocs attribués non marqués (580).
PCT/US1992/006419 1991-08-08 1992-08-03 Procede et appareil destine a identifier des fuites de memoire et a rechercher des pointeurs dans un programme informatique WO1993003435A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US742,259 1985-06-07
US74225991A 1991-08-08 1991-08-08

Publications (1)

Publication Number Publication Date
WO1993003435A1 true WO1993003435A1 (fr) 1993-02-18

Family

ID=24984117

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1992/006419 WO1993003435A1 (fr) 1991-08-08 1992-08-03 Procede et appareil destine a identifier des fuites de memoire et a rechercher des pointeurs dans un programme informatique

Country Status (2)

Country Link
AU (1) AU2423092A (fr)
WO (1) WO1993003435A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778525A1 (fr) * 1995-12-04 1997-06-11 NCR International, Inc. Procédé et dispositif pour détecter des fuites de mémoire
GB2342470A (en) * 1998-10-09 2000-04-12 Ibm A memory management system and method for a data processing system
US6523141B1 (en) * 2000-02-25 2003-02-18 Sun Microsystems, Inc. Method and apparatus for post-mortem kernel memory leak detection
US6675379B1 (en) 1999-09-07 2004-01-06 International Business Machines Corporation Automatic removal of array memory leaks
DE102006029138A1 (de) * 2006-06-22 2007-12-27 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren und Computerprogrammprodukt zur Detektion von Speicherlecks
EP1990724A1 (fr) * 2007-05-09 2008-11-12 Telefonaktiebolaget LM Ericsson (publ) Procédé pour localiser les fuites de ressources pendant le développement d'un programme informatique
US7500079B2 (en) 2006-07-31 2009-03-03 Microsoft Corporation Detection of memory leaks
US8429620B2 (en) 2008-06-27 2013-04-23 International Business Machines Corporation Memory leak diagnosis
CN104636256A (zh) * 2015-02-17 2015-05-20 中国农业银行股份有限公司 一种内存访问异常的检测方法及装置
EP2960798A1 (fr) * 2014-06-27 2015-12-30 Sap Se Détection de fuite de mémoire automatique
US9778969B2 (en) 2014-06-27 2017-10-03 Sap Se Automatic memory leak detection
CN115080235A (zh) * 2022-06-15 2022-09-20 北京航空航天大学 针对Shadow Memory内存泄漏检测机制的内存压缩方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4907151A (en) * 1988-09-30 1990-03-06 Digital Equipment Corporation System and method for garbage collection with ambiguous roots
US4989134A (en) * 1987-03-20 1991-01-29 Hewlett-Packard Company Method and apparatus for enhancing data storage efficiency
US5025367A (en) * 1986-05-29 1991-06-18 Victoria University Of Manchester Storage allocation and garbage collection using liberate space tokens

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5025367A (en) * 1986-05-29 1991-06-18 Victoria University Of Manchester Storage allocation and garbage collection using liberate space tokens
US4989134A (en) * 1987-03-20 1991-01-29 Hewlett-Packard Company Method and apparatus for enhancing data storage efficiency
US4907151A (en) * 1988-09-30 1990-03-06 Digital Equipment Corporation System and method for garbage collection with ambiguous roots

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Fundamentals of Data Structures", HOROWITZ et al., 1983, pg. 169-170. *
USENIX, Summer, 16 February 1988, BARACH et al., "A Memory Allocation Profiler for C and LISP Programs", see pages 1-13. *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778525A1 (fr) * 1995-12-04 1997-06-11 NCR International, Inc. Procédé et dispositif pour détecter des fuites de mémoire
US5689707A (en) * 1995-12-04 1997-11-18 Ncr Corporation Method and apparatus for detecting memory leaks using expiration events and dependent pointers to indicate when a memory allocation should be de-allocated
GB2342470A (en) * 1998-10-09 2000-04-12 Ibm A memory management system and method for a data processing system
US6675379B1 (en) 1999-09-07 2004-01-06 International Business Machines Corporation Automatic removal of array memory leaks
GB2357866B (en) * 1999-09-07 2004-06-23 Ibm Method, apparatus and computer software for memory management
US6523141B1 (en) * 2000-02-25 2003-02-18 Sun Microsystems, Inc. Method and apparatus for post-mortem kernel memory leak detection
US8504996B2 (en) 2006-06-22 2013-08-06 Dspace Digital Signal Processing And Control Engineering Gmbh Method and computer programming product for detecting memory leaks
DE102006029138A9 (de) * 2006-06-22 2008-05-21 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren und Computerprogrammprodukt zur Detektion von Speicherlecks
DE102006029138A1 (de) * 2006-06-22 2007-12-27 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren und Computerprogrammprodukt zur Detektion von Speicherlecks
US7500079B2 (en) 2006-07-31 2009-03-03 Microsoft Corporation Detection of memory leaks
EP1990724A1 (fr) * 2007-05-09 2008-11-12 Telefonaktiebolaget LM Ericsson (publ) Procédé pour localiser les fuites de ressources pendant le développement d'un programme informatique
WO2008138795A1 (fr) * 2007-05-09 2008-11-20 Telefonaktiebolaget Lm Ericsson (Publ) Procédé pour localiser des fuites de ressource pendant le développement d'un logiciel
US8429620B2 (en) 2008-06-27 2013-04-23 International Business Machines Corporation Memory leak diagnosis
EP2960798A1 (fr) * 2014-06-27 2015-12-30 Sap Se Détection de fuite de mémoire automatique
US9778969B2 (en) 2014-06-27 2017-10-03 Sap Se Automatic memory leak detection
CN104636256A (zh) * 2015-02-17 2015-05-20 中国农业银行股份有限公司 一种内存访问异常的检测方法及装置
CN104636256B (zh) * 2015-02-17 2017-10-24 中国农业银行股份有限公司 一种内存访问异常的检测方法及装置
CN115080235A (zh) * 2022-06-15 2022-09-20 北京航空航天大学 针对Shadow Memory内存泄漏检测机制的内存压缩方法

Also Published As

Publication number Publication date
AU2423092A (en) 1993-03-02

Similar Documents

Publication Publication Date Title
Boehm et al. Garbage collection in an uncooperative environment
US8549503B2 (en) Detecting dangling pointers and memory leaks within software
US6249793B1 (en) Mostly concurrent compaction in a garbage collection system
US5848423A (en) Garbage collection system and method for locating root set pointers in method activation records
EP0574884B1 (fr) Procédé et système d'ordinateur de gestion de mémoire
Bartlett Compacting garbage collection with ambiguous roots
US6658652B1 (en) Method and system for shadow heap memory leak detection and other heap analysis in an object-oriented environment during real-time trace processing
US7310718B1 (en) Method for enabling comprehensive profiling of garbage-collected memory systems
EP0959409B1 (fr) Récupération dynamique de mémoire sans assistance de compilateur ou d'éditeur de liens
US7313661B1 (en) Tool for identifying causes of memory leaks
US7827538B2 (en) Memory leak detection
US4907151A (en) System and method for garbage collection with ambiguous roots
US7506129B2 (en) Memory leak detection
US7711920B2 (en) Method and system for dynamically managing storage of data objects generated during execution of a computer program
US8255887B2 (en) Method and apparatus for re-using memory allocated for data structures used by software processes
US6795836B2 (en) Accurately determining an object's lifetime
US6523141B1 (en) Method and apparatus for post-mortem kernel memory leak detection
US7325106B1 (en) Method for monitoring heap for memory leaks
EP0864975A2 (fr) Détection d'erreurs de concurrence dans des programmes multifiles
US20070234296A1 (en) Software variation for robustness through randomized execution contexts
WO1993003435A1 (fr) Procede et appareil destine a identifier des fuites de memoire et a rechercher des pointeurs dans un programme informatique
US8478738B2 (en) Object deallocation system and method
US7676511B2 (en) Method and apparatus for reducing object pre-tenuring overhead in a generational garbage collector
US7072918B2 (en) Remembered-set scrubbing to remove stale entries in an incremental garbage collector
US7870170B2 (en) Method and apparatus for determining leaks in a Java heap

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AT AU BB BG BR CA CH CS DE DK ES FI GB HU JP KP KR LK LU MG MN MW NL NO PL RO RU SD SE

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL SE BF BJ CF CG CI CM GA GN ML MR SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA