1# Memory Leak Check<a name="EN-US_TOPIC_0000001078876382"></a> 2 3- [Basic Concepts](#section1026719436293) 4- [Function Configuration](#section13991354162914) 5- [Development Guidelines](#section95828159308) 6 - [How to Develop](#section369844416304) 7 - [Development Example](#section460801313313) 8 9 10## Basic Concepts<a name="section1026719436293"></a> 11 12As an optional function of the kernel, memory leak check is used to locate dynamic memory leak problems. After this function is enabled, the dynamic memory automatically records the link registers \(LRs\) used when memory is allocated. If a memory leak occurs, the recorded information helps locate the memory allocated for further analysis. 13 14## Function Configuration<a name="section13991354162914"></a> 15 161. **LOSCFG\_MEM\_LEAKCHECK**: specifies the setting of the memory leak check. This function is disabled by default. To enable this function, configure it in **Debug-\> Enable Function call stack of Mem operation recorded**. 172. **LOS\_RECORD\_LR\_CNT**: number of LRs recorded. The default value is **3**. Each LR consumes the memory of **sizeof\(void \*\)** bytes. 183. **LOS\_OMIT\_LR\_CNT**: number of ignored LRs. The default value is **2**, which indicates that LRs are recorded from the time when **LOS\_MemAlloc** is called. You can change the value based on actual requirements. This macro is configured because: 19 - **LOS\_MemAlloc** is also called internally. 20 - **LOS\_MemAlloc** may be encapsulated externally. 21 - The number of LRs configured by **LOS\_RECORD\_LR\_CNT** is limited. 22 23 24Correctly setting this macro can ignore invalid LRs and reduce memory consumption. 25 26## Development Guidelines<a name="section95828159308"></a> 27 28### How to Develop<a name="section369844416304"></a> 29 30Memory leak check provides a method to check for memory leak in key code logic. If this function is enabled, LR information is recorded each time when memory is allocated. When **LOS\_MemUsedNodeShow** is called before and after the code snippet is checked, information about all nodes that have been used in the specified memory pool is printed. You can compare the node information. The newly added node information indicates the node where the memory leak may occur. You can locate the code based on the LR and further check whether a memory leak occurs. 31 32The node information output by calling **LOS\_MemUsedNodeShow** is in the following format: Each line contains information about a node. The first column indicates the node address, based on which you can obtain complete node information using a tool such as a GNU Debugger \(GDB\). The second column indicates the node size, which is equal to the node header size plus the data field size. Columns 3 to 5 list the LR addresses. You can determine the specific memory location of the node based on the LR addresses and the assembly file. 33 34``` 35node size LR[0] LR[1] LR[2] 360x10017320: 0x528 0x9b004eba 0x9b004f60 0x9b005002 370x10017848: 0xe0 0x9b02c24e 0x9b02c246 0x9b008ef0 380x10017928: 0x50 0x9b008ed0 0x9b068902 0x9b0687c4 390x10017978: 0x24 0x9b008ed0 0x9b068924 0x9b0687c4 400x1001799c: 0x30 0x9b02c24e 0x9b02c246 0x9b008ef0 410x100179cc: 0x5c 0x9b02c24e 0x9b02c246 0x9b008ef0 42``` 43 44> **CAUTION:** 45>Enabling memory leak check affects memory application performance. LR addresses will be recorded for each memory node, increasing memory overhead. 46 47### Development Example<a name="section460801313313"></a> 48 49This example implements the following: 50 511. Calls **OsMemUsedNodeShow** to print information about all nodes. 522. Simulates a memory leak by requesting memory without releasing it. 533. Calls **OsMemUsedNodeShow** to print information about all nodes. 544. Compare the logs to obtain information about the node where a memory leak occurred. 555. Locate the code based on the LR address. 56 57**Sample Code** 58 59The sample code is as follows: 60 61``` 62#include <stdio.h> 63#include <string.h> 64#include "los_memory.h" 65#include "los_config.h" 66 67void MemLeakTest(void) 68{ 69 OsMemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); 70 void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); 71 void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); 72 OsMemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); 73} 74``` 75 76**Verification** 77 78The log is as follows: 79 80``` 81node size LR[0] LR[1] LR[2] 820x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc 830x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc 840x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e 850x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a 860x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 87 88node size LR[0] LR[1] LR[2] 890x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc 900x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc 910x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e 920x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a 930x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 940x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 950x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 96``` 97 98The difference between the two logs is as follows. The following memory nodes are suspected to have blocks with a memory leak. 99 100``` 1010x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 1020x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 103``` 104 105The following is part of the assembly file: 106 107``` 108 MemLeakTest: 109 0x80041d4: 0xb510 PUSH {R4, LR} 110 0x80041d6: 0x4ca8 LDR.N R4, [PC, #0x2a0] ; g_memStart 111 0x80041d8: 0x0020 MOVS R0, R4 112 0x80041da: 0xf7fd 0xf93e BL LOS_MemUsedNodeShow ; 0x800145a 113 0x80041de: 0x2108 MOVS R1, #8 114 0x80041e0: 0x0020 MOVS R0, R4 115 0x80041e2: 0xf7fd 0xfbd9 BL LOS_MemAlloc ; 0x8001998 116 0x80041e6: 0x2108 MOVS R1, #8 117 0x80041e8: 0x0020 MOVS R0, R4 118 0x80041ea: 0xf7fd 0xfbd5 BL LOS_MemAlloc ; 0x8001998 119 0x80041ee: 0x0020 MOVS R0, R4 120 0x80041f0: 0xf7fd 0xf933 BL LOS_MemUsedNodeShow ; 0x800145a 121 0x80041f4: 0xbd10 POP {R4, PC} 122 0x80041f6: 0x0000 MOVS R0, R0 123``` 124 125The memory node addressed by **0x080041ee** is not released after being requested in **MemLeakTest**. 126 127
