Method and system for tracking use of memory

Abstract

A method and system for tracking memory allocation and release activities to detect memory leaks, buffer overflow, and release type mismatch errors in a computing system. The memory tracker calculates the necessary size of the allocated memory block and calls a function provided by an operating system to allocate and release the original memory block. The original memory block is formatted as an allocated memory block. The index data structure stores the allocated memory blocks. And the user memory address is used as an index key value. When the program releases the memory, the memory block is removed from the indexed data structure. When the memory tracker is terminated, memory blocks remaining in the index data structure are considered as memory leaks. And the memory tracker adds bytes at the tail of the memory block to perform integrity verification, and detects possible buffer overflow errors. And adding a memory allocation type in the allocated memory block for releasing type mismatching errors.

Description

Technical Field

[0001] This case generally relates to the field of computer memory, and more specifically, to a method and system for tracking memory usage. Background Art

[0002] Embodiments herein relate generally to computer memory, and more particularly to a method and system for tracking memory usage.

[0003] Memory (e.g., random access memory, or RAM) is a crucial component of a computer system. The operating system, which manages the general operation of a computer, also manages memory. The component or software module within an operating system that manages memory (through a process called memory allocation) is the memory allocator. The memory allocator provides memory allocation and deallocation functionality for user programs to use shared memory blocks. C and C++ are two programming languages ​​used to create software systems that run on computers. Buffer overflows, memory leaks, and deallocation type mismatches are common problems in C and C++ programs.

[0004] An example of a memory leak occurs when a computer program allocates a block of memory and then fails to free it. A memory leak can cause the entire computing system to slow down or even crash.

[0005] A buffer overflow occurs when a program uses more memory than the bounds of its allocated memory block. This can cause the program to incorrectly read data or overwrite the contents of other memory blocks. A buffer overflow can cause the running system to malfunction or crash.

[0006] In C and C++, memory allocation is typically done using the well-known "malloc()," "realloc()," "cal loc()," "new," and "new[]" functions / operators. Memory allocated by "malloc()," "realloc()," and "cal loc()" must be released using the "free()" function / command. Memory allocated by "new[]" must be released using the "delete[]" operator / function. Memory allocated by "new" must also be released using the "delete" operator / function. When the wrong release method is used to release memory, a memory release type mismatch occurs. This mismatch can lead to system crashes or memory leaks. Summary of the Invention

[0007] A method and system for tracking memory allocation and deallocation activities for detecting memory leaks, buffer overflows, and deallocation type mismatch errors in a computing system. In one embodiment, a memory tracker implements standard C and C++ memory allocation and deallocation functions / operators to capture user program requests. Based on the requested memory size, the memory tracker calculates the necessary size of the allocated memory block and calls functions provided by the operating system / hosting system to allocate and deallocate the original memory block. The memory tracker formats the original memory block into an allocated memory block and uses an index data structure to store all allocated memory blocks. In one embodiment, a red-black tree is used as the index data structure and the user memory address is used as the index key value. When the program releases memory, the memory block is removed from the index data structure. When the memory tracker terminates, the memory block remaining in the index data structure is considered a memory leak.

[0008] The memory tracker adds several bytes to the end of each user memory block to perform integrity checks on the allocated memory block and detect possible buffer overflow errors. The memory tracker also adds a memory allocation type to the allocated memory block to report possible free type mismatch errors.

[0009] Five macros are defined to replace C and C++ memory allocation functions / operators, including malloc, cmalloc, realloc, new, and new[]. These macros combine memory allocation and setting the caller source file information into a single logical programming line. Several event handlers are defined to allow user programs to create their own event handlers for memory allocation, deallocation, buffer overflow, memory leak, and deallocation type mismatch events. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Some implementations of the invention are described in detail below and are linked to accompanying figures, in which the numerals represent the corresponding parts of the figures.

[0011] Figure 1 is a block diagram of a system for tracking memory allocation activity in a software application according to one embodiment of the present technology.

[0012] Figure 2 is a block diagram illustrating allocated memory block and user memory block data structures according to one embodiment of the present invention.

[0013] Figure 3 is a flowchart of a memory allocation method according to one embodiment of the present technology.

[0014] Figure 4A is a flow chart of a method for releasing a memory block in a computing device according to one embodiment of the present technology.

[0015] Figure 4B is a flow chart of a method for reallocating memory blocks in a computing device according to one embodiment of the present technology.

[0016] Figure 4C is a flowchart of an implementation of the "calloc()" method in C language, which sets the allocated memory value to 0 before returning the memory block pointer to the caller according to one embodiment of the present technology.

[0017] Figure 5 is a flow chart of a method for terminating memory tracking in a computing device according to one embodiment of the present technology.

[0018] Figure 6 is a screenshot of a code snippet declaring a memory allocation macro according to one embodiment of the present technology.

[0019] Figure 7 It is a screenshot of a code snippet declaring the BLMal loc() function, the BLReal loc() function, and the BLCalloc() function according to an embodiment of the present technology.

[0020] Figure 8 is a screenshot of a code snippet from an implementation of the present technology, declaring data types used by the memory tracker.

[0021] Figure 9 is a screenshot of a small code snippet that defines a memory tracker event handler according to an implementation of the present technology.

[0022] Figure 10 is a screenshot of an example memory usage report according to an embodiment of the present technology.

[0023] Figure 11 This is a block diagram of a computing device used to implement the implementation plan of this briefing document. Specific implementation plan

[0024] This briefing uses memory allocation functions in programming languages ​​(e.g., C and C++) to capture program requests. In some implementations, the memory allocation function can record source file information of the memory allocation caller. As you know, the subject system and process are characterized by being fast and eliminating corner cases, escaping memory leak errors. Because some implementations may be fast and small, the memory tracker of this briefing can be integrated into the C and C++ standard libraries and become the default feature of these two languages. It is foreseeable that C and C++ will become safer languages ​​to use after integrating just-in-time technology. The implementation tracked memory allocation and deallocation activities to report any memory leaks and deallocation type mismatch errors. A feature also checks the integrity of the allocated memory block to report possible buffer overflow errors.

[0025] See also Figure 1 . Figure 1 1 is an overview diagram of a system 100 according to an embodiment of the present technology. It includes components in a computer system related to the innovation. System 100 may include a user program (101), a memory tracker module (102), a memory allocator module (103), and memory (104). The user program (101) may be C, C++, or other program that calls the memory tracker module (102) to provide the functionality to allocate and release memory blocks. The memory tracker module (102) is a software engine that implements logic routines for tracking memory usage according to an embodiment of the present technology. In some embodiments, the memory tracker module (102) includes an allocated memory tree module ("AMT") (111) for tracking the locations of allocated memory blocks 112, 113, and 114. The memory tracker module (102) may include a memTai lBytesSize (115) variable and a reserveNewAl locationMemory (116) variable in some embodiments. The memory allocator module (103) may be a memory allocator provided by the host system. The memory allocator module (103) manages memory (RAM) 104 and provides raw memory allocation and deallocation functionality to the memory tracker module (102). In some embodiments, the memory tracker module (102) generates a memory usage summary report (117), a memory leak report (118), a buffer overflow report (119), and a deallocation type mismatch report (120).

[0026] In one embodiment, the memory tracker module (102) includes two deliverable files, one is a static library (LMemTracker.lib) and the other is a header file (LMemTracker.h). The static library (LMemTracker.lib) implements all the memory tracker logic and provides all C and C++ memory allocation and deallocation functions, including malloc, realloc, call loc, free, new, deletion, new[] and delete[]. The memory tracker is a C++ class that includes an allocation memory tree (AMT) (111), memTai lBytesSize, reserveNewAl locationMemory and a name. The class constructor initializes the memory tracker. The destructor terminates the memory tracker. Allocated memory blocks (AMBs) and user memory blocks (UMBs) are declared by C / C++ language structures.

[0027] Three main functions are created in the memory tracker module (102). The function AllocateMemory() is used to implement the memory allocation workflow. The functions that implement mal loc, cal loc, new, and new[] call Al locateMemory() to complete the task. The function ReleaseMemory() is used to implement the memory release workflow. The functions that implement free, deletion, and delete[] call ReleaseMemory() to complete the task. The Real locMemory() function is a Realloc() function that uses the memory allocation and free logic defined in the memory tracker and calls the reallocation function provided by the host system to implement the logic defined in the C language. This is a composite function. The real loc() function provided by the memory tracker calls ReallocMemory() to complete the task.

[0028] The header file (LMemTracker.h) should be included in the program that needs to use the memory allocation macros. The macro logic is shown in Figure 6 These definitions should be part of the header file, and additional definitions may need to be added for specific hosting platforms.

[0029] The memory tracker module (102) can provide all C and C++ memory allocation and deallocation functions, or can implement only some of them as needed. The memory tracker module (102) can also create other memory allocation and deallocation functions for specific environments.

[0030] As long as the memory block can be located quickly, the index data structure used to store the allocated memory block (111) can be a red-black tree or other data structure.

[0031] If the memory tracker module (102) only uses a fixed tail byte size, "memTailBytesSize" (115) can be replaced with a constant.

[0032] The allocated memory block (AMB 211) and the user memory block (UMB 212) can be combined into a single data structure, requiring only a single system memory allocation call to obtain raw memory for both. In this case, the user memory pointer (203) can be removed because it can be calculated from the address of the tree node (205); however, it is recommended to retain it for simplicity and clarity. If the underlying system provides different memory pools that can allocate memory blocks with different permissions or speeds, separating the allocated memory block (211) and the user memory block (212) may be a better choice.

[0033] The tail bytes of the user memory block (210) can be filled with a fixed byte sequence or by using an integrity check algorithm that calculates the byte sequence. It is recommended to use an integrity check algorithm for filling because any changes to the tail bytes or the fields involved in the calculation will cause verification to fail. This will allow the memory tracker module (102) to report more possible errors. In addition, a random value byte sequence that may be generated when the memory tracker is started can be added as one of the inputs to the integrity byte calculation. This will make it more difficult for malware to generate valid tail bytes.

[0034] Figure 2 (right Figure 1 The structure in FIG2 is referred to as architecture 200, and according to an embodiment, the architecture defines allocated memory block (AMB 211) and user memory block (UMB 212) data structures. At a high level, the AMB (211) contains components 201 to 208. The UMB (212) contains components 209 and 210. The composition of the AMB (211) and the UMB (212) will be described in detail according to the embodiment. Pointer ("ptr") 203 is a pointer in the AMB (211) to the user memory (209) in the UMB (212). The allocated memory tree (111) is an index data structure that can store and quickly find allocated memory blocks (211). In one embodiment, a red-black tree is used for the index data structure. When memory is allocated, an AMB (211) is added to the AMT (111), and when memory is released, the AMB (211) is removed from the AMT (111). When the memory tracking module (102) is turned off, all AMBs (211) on the AMT (111) should have been removed. When the memory tracking module (102) is turned off, the remaining AMBs (211) in the AMT (111) may be considered a memory leak, except that isReserved (202) in the AMB (211) is set to true for other purposes.

[0035] One embodiment of the AMB (211) may include the following components 201-208:

[0036] The memory allocation type (al locType) (201) represents the memory allocation function or operator of the request (mal loc, new, new[], or other) program. When allocating memory, the request type is stored in the memory allocation type (201). When freeing memory, the free request type is compared with the value stored in the memory allocation type (201). If they do not match, an allocation type mismatch report (120) may be generated in response to the mismatch.

[0037] Variable isReserved (202) indicates whether the memory block (AMB 211) is reserved. Reserved AMBs are not counted as memory leaks. In one embodiment, the memory tracker module (102) provides a function that requires an input of 1 or 0 to switch the tracker's reserve value (116) to 1 or 0. If the tracker's reserve value (116) is 1, the newly allocated AMB (211) can be reserved, otherwise the AMB is not reserved. This feature is particularly useful when using the memory tracker module (102) in an operating system kernel, because some components in the operating system cannot be released, otherwise the system will not be able to output a memory tracking report.

[0038] The user memory pointer (203) points to the beginning of the user memory block (212). The pointer (203) can also be returned to the user program (101). In one embodiment, this value is also used as a sort key to sort all AMBs (211) in the AMT (111).

[0039] size(204) stores the size of user memory(209) in bytes.

[0040] amtNode (205) is the node data of the index data structure. In one embodiment, this is a red-black tree node that can be added in AMT (111).

[0041] FilePath (206) is the memory for keeping the source program file path of the memory allocation function caller. In one embodiment, it exists in the debug version, but is removed in the release version.

[0042] func(207) is used to store the memory allocated to the caller source program function name. In one embodiment, it is present in debug builds but is removed in release builds.

[0043] Line (208) is the source code line number where the memory allocation function is called. In one embodiment, it is present in debug builds but removed in release builds.

[0044] In one embodiment, the user memory block (212) includes the components 209 and 210 described below:

[0045] User memory (209) may be memory allocated for user programs. It is pointed to by pointer (203) and returned to the memory allocation function caller.

[0046] Tail bytes (210) is an array of bytes at the end of user memory (209). It is used for integrity checking and detecting possible buffer overflow errors. In one embodiment, tail bytes (210) is a four-byte array, each byte containing a different prime byte array value in the range of 131 to 251. The predefined byte array contents are copied to the tail bytes (210) of all UMBs (212). When freeing memory, the memory tracker module (102) checks whether the tail bytes (210) contents have changed. If there has been a change, the memory tracker module (102) may generate a buffer overflow report (119).

[0047] In another embodiment, the tail byte (210) is a four-byte array filled with the first four bytes of the SHA1, SHA2 or CRC32 value bytes of the concatenation of (allocType) (201), isReserved (202), ptr (203), size (204), and a four-byte random array generated when the memory tracker starts. When the memory is released, the value byte is recalculated and compared with the value byte stored in the tail byte (210). If the values ​​match, the integrity of the AMB (211) is verified; otherwise, a buffer overflow report (119) is generated. This check actually verifies the integrity of selected fields in the AMB (211) and the tail byte (210). Any changes to these fields will cause the verification to fail. Since more and more systems have hardware-accelerated SHA1, SHA2, CRC32 and other integrity checking functions, it is preferred to use this dynamically calculated tail byte value (210). The tail byte length (115) can be configured when the memory tracker module (102) starts. A longer tail byte length provides more protection at the expense of more memory. A recommended length is 4 bytes. There are many good algorithms for calculating the tail byte (210), such as SHA1, SHA2, MD5, and CRC32. SHA1 and SHA2 are recommended.

[0048] Figure 3 A memory allocation process (300) (sometimes generally referred to as 'process' (300)') is given according to one embodiment. Figure 3 The steps shown can sometimes be traced back to Figure 1 and Figure 2Elements in. The process (300) is responsible for handling memory allocation requests. As an initial step, the user program (101) sends a memory allocation request (301) to the memory tracker module (102). Based on the requested memory size, the memory tracker module (102) calculates (302) the memory size required for the AMB (211) and UMB (212). The memory tracker module (102) calls the memory allocator (103) to allocate (303) raw memory. The memory tracker module (102) uses the raw memory to build (304) the AMB (211) and UMB (212). The AMB (211) is added (305) to the AMT (111). The memory tracker module (102) can update (306) the memory usage summary (117) file. The memory tracker module (102) can return (307) the user memory pointer (203) to the user program (101).

[0049] Figure 4A FIG. 4 is a memory release process (400) (sometimes generally referred to as 'process' (400)') according to an embodiment. The process (400) is responsible for processing memory release requests. Figure 4A The steps shown may also sometimes be referred to as Figure 1 and Figure 2elements in. The user program (101) can send a memory release request (401) to the memory tracking module (102). The memory tracker module (102) can use the input pointer to calculate (402) the AMB (211) pointer. The memory tracker module (102) can calculate (403) the tail byte (210). The memory tracker module (102) can compare (404) the calculation result in the block (403) with the content stored in the tail byte (210). If the comparison result (404) is incorrect, this process may generate (405) a buffer overflow report (119). The memory tracker module (102) can determine whether the allocType (201) of the AMB (211) matches the requested release type (406). If the allocType (201) does not match the release type, a release type mismatch report (120) is generated (407). The memory tracker module (102) may attempt to remove the (408) AMB (211) from the AMT (111). The memory tracker module (102) may check (409) whether the removal was successful. If successful, the memory tracker module (102) may update (410) the memory usage summary (117), otherwise the process may end (412). The memory tracker module (102) may call the memory release function provided by the memory allocator (103) to release (411) the raw memory. At module (412), the memory tracker module (102) may return control to the user program (101). Process 400 can be rearranged so that the process includes: verifying the tail byte, checking whether the release type matches the allocation type, removing the allocated memory block (AMB) from the allocated memory tree (AMT), releasing the raw memory, and calling the specified event handler when the event occurs.

[0050] See also Figure 4B , shows a memory reallocation process 450 of one embodiment. The process 450 is responsible for adjusting the size of an allocated memory block. Steps such as Figure 4B The steps in Figure 1 and Figure 2 A user program (101) can send a request (451) to the memory tracking module (102) to reallocate memory. The memory tracker module (102) can determine (452) whether the existing memory pointer (oldMem) in the input parameter is null (oldMem == NULL) and whether the requested new memory size (newSize) is 0.

[0051] (newSize>0). If both conditions are met, the memory tracking module (102) may issue (453) a call to memory allocation request (301) to allocate memory (it will call the memory allocator (103) to allocate (454) the original memory block). The memory tracker module (102) may return the user pointer (203) to the user program (101). If any of the conditions in module (452) are not met, the memory tracker module (102) may determine (455) whether the existing memory pointer (oldMem) is not null (oldMem!=NULL) and whether the requested new memory size (newSize) is zero (newSize==0). If both conditions are met, the memory tracker (102) issues (456) a call to release (401) memory (it will call the memory allocator (103) to release the original memory block). The memory tracker module (102) may return (459) NULL to the user program (101) and go to end step 464. When any of the conditions in module (455) are not met, the memory tracker module (102) can determine whether the existing memory pointer (oldMem) in (458) is null (oldMem == NULL) and whether the requested new memory size (newSize) is zero (newSize == 0). If both conditions are met, the memory tracker module (102) may return a NULL value to the user program (101) and the process may end (464). If any of the conditions in 458 are not met, the memory tracker module (102) can call the process (401) to release (460) the memory and retain the original memory, and then call the memory allocator (103) to reallocate (461) the memory. The memory tracker module (102) can construct (462) the AMB (211) and the UMB (212). The memory tracker module (102) can return (463) the user pointer (203) to the user program (101).

[0052] See also Figure 4C , showing a process 470 of implementing a C standard function call (), Figure 4C The steps shown may also sometimes be referred to as Figure 1 and Figure 2 The user program (101) can call calloc() to allocate memory (471). The memory tracker (102) can call function (301) to allocate memory and check the result (474). If the allocation is successful, all memory elements are set to zero (476) and the user memory pointer (203) is returned (477) to the user program (478). Otherwise, NULL (475) is returned to the user program (478).

[0053] See also Figure 5 , shows a process 500 for terminating memory tracker operations according to one embodiment. The process 500 is responsible for terminating the operation of the memory tracker module (102). Figure 5 The steps shown may also sometimes be referred to as Figure 1 and Figure 2 elements in. The user program (101) can send a request (501) to the memory tracker module (102) to terminate memory tracking. The memory tracker module (102) can check (502) whether an AMB (211) exists in the AMT (111). If there is no AMB (211), the memory tracker module (102) can generate (503) a final memory usage summary report (117). The memory tracker module (102) can return control (504) to the user program (101). If there is an AMB (211), the memory tracker module (102) can retrieve (505) the first AMB (211) in the AMT (111). If isReserved (202) in the AMB (211) is correct, the memory tracker module (102) can check (506). If true, the process can return to (502) to continue the next check. If isReserved is not true (or false), the memory tracker module (102) may generate (507) a memory leak report (118). The memory tracker module (102) may determine (508) whether the tail byte (210) in the UMB (212) is valid. If so, the process may return to (502) to continue with the next check. If the tail byte is not valid, the memory tracker module (102) may generate (509) a buffer overflow report (119) and return to (502) to continue with the next check.

[0054] The steps in process 500 can be rearranged as long as the process includes: removing allocated memory blocks from the allocated memory tree, reporting memory leaks of non-reserved blocks, checking the tail bytes of non-reserved blocks, reporting buffer overflows of non-reserved blocks with invalid tail bytes, and calling an event handler when the event occurs.

[0055] See also Figure 6 , provides a screenshot 600 showing a code snippet declaring a memory allocation macro for an embodiment of the present memory tracking technique. The example shown is written in the C and C++ programming languages. See example declarations 601-606. However, it should be understood that these are merely examples, and other declaration types are within the scope of this disclosure.

[0056] The code snippet shown declares five macros that combine memory allocation with saving caller source code information. This code snippet illustrates how to leverage existing C and C++ features to obtain caller source file information at compile time for fast and friendly error reporting. The left column is the line number. The right column is the C and C++ code. Line 20 declares the macro LNew(type) (602), which is intended to replace the new operator in C++. The returned pointer needs to be released by the C++ delete operator. Line 21 declares the macro LNewArray(type, size) (603), which is intended to replace the C++ new[] operator; the returned pointer needs to be released by the delete[] operator. Line 29 declares the macro LMalloc(size) (604), which is intended to replace the C mal loc() function; the returned pointer needs to be released by the free() function. Line 30 declares the macro LReal loc(oldPtr, newSize) (605), which is intended to replace the C real loc() function; the returned pointer needs to be released by free(). Lines 19 and 28 check whether compile-time switch_DEBUG (601) is declared; if so, the macro adds the caller source file information; otherwise, the source file information is discarded to reduce system memory usage.

[0057] It is worth noting that existing code and third-party programs cannot access the functionality provided by the newly declared macros. The currently disclosed memory tracker module (102) can still report memory leaks, buffer overflows, and free type mismatch errors, whether used by user programs or any third-party C and C++ programs. When the macros are not used, the only thing missing from the error report is the allocation source file information. It is important to be able to report errors in existing code and third-party C and C++ libraries, because third-party programs may be compiled as binary library files and may not provide source code.

[0058] See also Figure 7 , screenshot 700 shows the code snippets of BLMalloc() function (701), BLRealloc() function (702), and BLCalloc() (703) function. These functions are Figure 6 604, 605, and 606 in . This code can be placed in a C file and included in a memory tracker project. The function BLSetFileInfo() is called in 600 and 700. It simply copies the input value into the AMB field.

[0059] See also Figure 8Screenshot 800 shows a code snippet that declares data types and event handlers used by a memory tracker, according to one embodiment. The example shown is code written in the C and C++ programming languages. Memory allocation types are declared at 801. Memory allocation data types and source code information structures are defined at 82.

[0060] The memory tracker defines several event handlers and allows user programs to create their own. These event handlers are called when events such as memory allocation, memory deallocation, memory leak detection, buffer overflow detection, and free type mismatch detection occur. The event handler function pointer type is declared in 803. The event handler pointer is declared in 804.

[0061] See also Figure 9 Screenshot 900 shows a code snippet defining a memory tracker event handler function in one implementation. The example code shown is written in C and C++ programming languages. An empty event handler function is defined at 901. The SetMemoryTrackerEventHandlers() function, defined at 902, is used to enable and disable the event handler. The user program can call this function at any time to toggle the handler on (input 1) or off (input 0).

[0062] See also Figure 10 Screenshot 1000 shows a sample memory usage report for one embodiment. Error report 1001 is an example of a free type mismatch report (120). Error report 1002 is an example of a buffer overflow report (119). 1003 is an example of a memory allocation point in a user program; the allocated memory contains the buffer overflow error reported in 1002. Error report 1004 is an example of a memory leak report (118). 1005 is an example of a memory usage summary report (117).

[0063] Examples of items included in the memory usage summary are shown below. In one embodiment, the following items are included.

[0064]

[0065] The above process can be performed in a memory tracker module (102) (see Figure 1 ) is implemented in . The memory tracker module (102) can provide standard C and C++ memory allocation and release functions to capture the requests of user programs. The functions provided are: new, new[], deletion, deletion[], malloc, real loc, cal loc, free. The logic of new, new[], malloc is as follows Figure 3 As shown. The logic of free, delete and delete[] is Figure 4A The logic of Realloc is described in Figure 4B The logic of Calloc is described in Figure 4C Described in .

[0066] The memory tracker calls operating system-provided functions to allocate and free raw memory blocks. An index data structure is used to store all allocated memory blocks. When the program frees memory, the memory blocks are removed from the index data structure. Before the memory tracker terminates, all memory blocks may have been removed from the index data structure. When the memory tracker is shut down, any memory blocks remaining in the index data structure, except for any memory blocks marked as reserved, are considered memory leaks.

[0067] The memory tracker of this document adds several bytes (tail bytes) at the end of each user memory block to detect possible buffer overflow errors. Tail Bytes (210) (see Figure 2 ) is either filled with a constant byte sequence or with bytes calculated using the selected integrity check algorithm. When the memory is freed, the byte value is calculated again using the same algorithm. The result is compared with the result stored in the tail byte (210). If they are different, the memory tracker module (102) generates a buffer overflow report (119) (see Figure 1 ).

[0068] When processing a memory release request, the memory allocation type (201) stored in the allocated memory block (211) is checked. If the release type does not match the allocation type, the memory tracker generates a release type mismatch report (120).

[0069] The order of items in an allocated memory block (211) can be rearranged as needed. However, the key field amtNode (205) has more protection space at the front in case of unexpected buffer overflow, and this should be kept in mind when arranging items in the AMB.

[0070] Common channels for reporting memory tracker events include log files, C and C++ standard output, and IDE debug output. In addition, user programs can create their own reporting methods in memory tracker event handlers.

[0071] The memory tracker module (102) can be used in an operating system kernel, a service application (daemon), or a regular application. For most service applications and regular applications, the memory tracker implementation can be declared as a global variable. When the application starts, the global variable will be loaded into the application's stack memory and automatically initialized. Moreover, when the application ends, the memory tracker's destructor will be automatically called to terminate the memory tracker. In this case, there are three steps to using the memory tracker module (102):

[0072] Include the memory tracker header file (LMemTracker.h) in your C and C++ source files that use the memory allocation macros. No modifications are required for C and C++ source files that do not use the macros.

[0073] Declare a global variable of the memory tracker class.

[0074] Link the user program with the memory tracker library.

[0075] When the memory tracker module (102) is used in the operating system kernel or some special applications, the system may need to precisely control the startup and shutdown steps. In this case, declaring the memory tracker instance as a global variable will not be an option. The memory tracker module (102) may need to be combined with the memory allocator and created at a specified memory address. In addition, the memory tracker module (102) may need to be created after initializing some key system components (such as the memory controller). When the system shuts down, the location where the memory tracker module (102) is terminated is also critical. The system may need to ensure that there is no memory allocation and deallocation activity after the memory track is terminated.

[0076] Some computing devices have multiple memory pools. Each memory pool may have different speeds and costs. The memory tracker module (102) can create multiple instances. Each instance provides tracking features for a memory pool. The C and C++ standard memory allocation and release functions work with the main memory pool. User programs can access other memory pools through the AllocateMemory() and ReleaseMemory() functions provided by the memory tracker, which can still report memory leaks and buffer overflow errors.

[0077] See also Figure 11, illustrates in detail a computing device 1100 in one embodiment. For example, computing device 1100 may be a mobile phone or computer server running a program that can benefit from the memory tracking features disclosed in the subject matter. In the role of a user device, computing device 1100 is typically a server, a desktop computer, a tablet or laptop computer, an all-in-one workstation, a mobile computing device (e.g., a smartphone), a smart wearable device (glasses, jewelry, a watch, an earpiece, etc.), or programmable electronics.

[0078] Components of computing device 1100 may include, but are not limited to, one or more processors or processing units 1110, one or more processors or processing units 1110, a system memory 1120 (e.g., RAM or other hardware storage device), data memory 1130, a computer program product 1140 having a set of program modules 1145 comprising files and executable instructions, and a bus system 1114 coupling various system components including system memory 1120 and processor(s) 1110. Specific embodiments generally include a memory tracker engine 1170, which, relative to memory tracker module 102, contains executable files for running the processes described above. Computer program product 1140 may be hardware (e.g., a memory element storing a software implementation of the embodiments described above) or a software instance that runs the memory tracking process. Memory tracker engine 1170 may be a separate component or integrated into computer program product 1140. The collection of program modules 1145 includes instructions for performing the memory tracking-related processes described above and for providing alerts.

[0079] In some embodiments, processing unit 1110 is a dedicated computer processor that implements the processes described above, including memory tracking and error detection.

[0080] Computing device 1100 can be described in the general context of computer system executable instructions, such as program modules 1145, which represent the software implementation of the system and the processes generally described above. Program modules 1145 generally implement the functions and / or implement the methods described above. Computing device 1100 may generally include various computer system readable media. Such media can be selected from any available media accessible by computing device 1100, including non-transitory, volatile and non-volatile media, removable and non-removable media, for use in or in connection with an instruction execution system, device, or apparatus. For example, computer-readable storage media may be, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination of the foregoing. System memory 1120 may include one or more computer system readable media, such as random access memory (RAM) and / or cache memory. By way of example only, data storage system 1130 may read from and write to a non-removable, non-volatile magnetic media device. System memory 1120 may include at least one program product 1140 having a set of program modules in the form of computer-executable instructions configured to perform the functions of the invention. Program product / utility 1140 has a set of program modules 1145 that may be stored in system memory 1120, by way of example and without limitation, as an operating system, one or more application programs, other program modules, and program data. Some embodiments may generate an electronic user interface (viewable and controllable from display screen 1150) that allows a user to input graphical objects for processing.

[0081] Computing device 1100 can communicate with one or more external devices, including, for example, an electronic display 1150, which in some embodiments can be configured for tactile response, such as a touchscreen display. User input from display 1150 can be registered and processed by processor 1110. Other devices can enable computing device 1100 to communicate with one or more other computing devices via hardwired or wireless means. This communication can be accomplished via input / output (I / O) interfaces / ports 1160. In some embodiments, I / O interfaces / ports 1160 can be specifically configured to handle certain aspects of the embodiments described herein, transforming computing device 1100 into a specialized machine. For example, as a processing point, I / O interfaces / ports 1160 can be configured to transmit messages related to memory allocations and memory block changes occurring externally to computing device 1100 (e.g., in a network environment), thereby enabling detection of sources affecting memory allocation tracking or memory allocation errors occurring internally within computing device 1100, external to computing device 1100.

[0082] Through I / O interface / port 1160, computing device 1100 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN) and / or a public network (e.g., the Internet) through a network adapter. Each operating system, one or more application programs, other program modules, program data, or some combination thereof may include an implementation of a network environment. In some embodiments, computing device 1100 may be a cloud computing node (not shown) connected to a cloud computing network. Computer computing device 1100 can be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices that are connected via a communication network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media, including memory storage devices.

[0083] As will be appreciated by those skilled in the art, various aspects of the disclosed invention may be embodied as a system, method, process, or computer program product. Accordingly, aspects of the present invention may take the form of a fully hardware implementation, a fully software implementation (including firmware, resident software, microcode, etc.), or a combination of software and hardware, which are generally referred to herein as "modules," "circuits," or "systems." For example, in certain hardware implementations, a "storage module" may be any one of system memory 1120 and data memory 1130, or any combination thereof. Furthermore, aspects of the present invention may be a computer program product embodied in one or more computer-readable media, embodying computer-readable program code.

[0084] According to embodiments of the present invention, aspects of the present invention are described with reference to block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block in the block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor 1110 of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device create a means for implementing the functions / behaviors specified in one or more blocks in the flowchart and / or block diagram.

[0085] It should be noted by those skilled in the art that the various components and modules can be arranged differently (e.g., arranged in a different order, or partitioned in a different manner) without departing from the scope of the subject technology. The foregoing description is intended to enable anyone skilled in the art to practice the various aspects described herein. The foregoing description provides various embodiments of the present technology, and the present technology is not limited to these embodiments. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects.

[0086] Thus, the claims are not limited to the aspects described herein, but are to be accorded the full scope consistent with the claim language, in which a reference to an element in the singular does not mean "one and only one of" unless specifically stated otherwise, but rather "one or more." The word "some" refers to one or more unless specifically stated otherwise. Pronouns in the masculine gender (e.g., his) include the feminine gender (e.g., she and its) and the neuter gender (e.g., her and its), and vice versa. Headings and subheadings, if any, are for convenience only and do not limit the invention.

[0087] Phrases like "aspect" do not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. Disclosures related to an aspect may apply to all configurations or to one or more configurations. An aspect may provide one or more examples. A phrase like "an aspect" may refer to one or more aspects, and vice versa. Phrases like "embodiment" do not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. Disclosures related to an embodiment may apply to all embodiments or to one or more embodiments. An embodiment may provide one or more examples. Phrases like "avatar" may refer to one or more avatars, and vice versa. Phrases like "configuration" do not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. Disclosures related to a configuration may apply to all configurations or to one or more configurations. A configuration may provide one or more embodiments. Phrases like "configuration" may refer to one or more configurations, and vice versa.

[0088] The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0089] All structural and functional equivalents to the various aspects described throughout this disclosure that are known or later come to be known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Furthermore, no information disclosed herein is intended to be made available to the public, regardless of whether such disclosure is expressly recited in the claims. Pursuant to 35 U.S.C. § 112(6), no claim element shall be construed unless the element is expressly recited as a “means-to-end” or, in the case of a method claim, as a “step-to-end.” Furthermore, to the extent the term “including,” “having,” or the like is used in the description or claims, such term is intended to be inclusive in a manner similar to the term “comprising” as it is interpreted when used as a transitional term in a claim.

[0090] Industrial Applications

[0091] The implementation of the invention can be used to track memory allocation and deallocation activities of a memory tracker to detect memory leaks, buffer overflows, and deallocation type mismatch errors in a computing system.

Claims

1. A memory tracker is a method for tracking memory allocation and deallocation activities to detect memory leaks, buffer overflows, and deallocation type mismatch errors in computing systems, including: Generate a first data structure, an Allocation Memory Block (AMB), for a plurality of respective user pointers, wherein each AMB includes a respective user pointer, a user memory size, an allocation type, and node data supporting adding the AMB to the indexed data structure; generating a second data structure, the indexed data structure being an allocated memory tree (AMT), configured to track each allocated memory block (AMB), wherein each allocated memory block is located by a memory pointer returned to a calling program; Generate a third data structure, User Memory Block (UMB), for each AMB, where the UMB includes the user memory size and a tail byte array, the tail byte array being configured to provide integrity checking and detect buffer overflows; Provides multiple memory allocation and deallocation functions and operators, including malloc, realloc, calloc, free, new, deletion, new[], and deletion[] to capture memory allocation and deallocation requests; Allocate and release memory blocks according to multiple memory allocation and release functions.

2. The method according to claim 1, further comprising using a red-black tree as an allocation memory tree (AMT) to track all AMBs, wherein the AMT is indexed by a user pointer in each AMB, and the node data in the AMB is red-black tree node data.

3. The method according to claim 1, further comprising: Copy a fixed sequence of prime byte array values ​​into the tail byte of each UMB; performing a buffer overflow verification method, the method comprising comparing the contents of the tail byte to a fixed byte sequence; If the tail byte content does not match the fixed byte sequence, a false value is returned; Returns a true value if the trailing byte contents match the fixed byte sequence.

4. The method according to claim 1, further comprising: Use SHA1, SHA2 or CRC32 to calculate the combination of the user pointer, user memory size, reserve indicator, allocation type and some random bytes generated when the memory tracker is started; Select and copy multiple bytes of the calculated merge result to the tail byte of UMB; Execute the buffer overflow verification method, which includes comparing the content of the tail byte with the calculated merge result, matching the value in the UMB tail byte.

5. The method according to claim 3 and 4, further comprising adjusting the length of a tail byte according to the system design requirements of the calling program.

6. The method according to claim 1, further comprising: Verify the tail byte when releasing a memory block; Determine whether the tail byte is verifiable; and generating a buffer overflow report in response to unverifiable tail bytes. 7 . The method of claim 1 , further comprising generating a memory leak report if a non-retained AMB exists in the AMT when the memory tracker terminates.

8. The method according to claim 1, further comprising using macro_FILE_, _func_, and _LINE_ provided by C and C++ to set source file information of the memory allocation caller in the AMB.

9. The method according to claim 8 further includes defining macros to replace malloc, calloc, realloc, new and new[] to merge memory allocation and setting caller source file information operations into one logical programming line.

10. The method of claim 9, further comprising adding a compile time switch to cause the memory tracker to set source code information for debug versions.

11. The method according to claim 1 further includes reporting source code information of a memory allocation caller in response to the occurrence of a memory leak, buffer overflow or release type mismatch error, wherein the memory allocation caller includes one or more of: a source file name, a function name, a line number, a process ID, a thread ID and a timestamp.

12. The method according to claim 1 further comprises providing an event handler function pointer to allow a user program to create an event handler to handle memory allocation, release, buffer overflow, memory leak and release type mismatch events.

13. The method according to claim 1 further comprises providing a function that allows a user program to track dynamic memory usage summary data.

14. The method of claim 1, further comprising providing an optional final memory usage summary report upon termination of the memory tracker.

15. The method according to claim 1, wherein the AMB comprises: An indicator indicating whether the memory block is reserved; the source file information of the memory allocation caller includes the source file path, function name, line number, process ID, thread ID, and timestamp. The method according to claim 1 , wherein the AMB and the UMB are combined into one memory block or separated into two memory blocks.

17. The method of claim 16, further comprising pointing a user pointer in the AMB to a beginning of the UMB user memory.

Images