harmony 鸿蒙Memory Leak Check
Memory Leak Check
Basic Concepts
As 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 mechanism 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.
Function Configuration
LOSCFG_MEM_LEAKCHECK specifies the setting of the memory leak check. This function is disabled by default. You can enable it in Debug-> Enable MEM Debug-> Enable Function call stack of Mem operation recorded.
LOS_RECORD_LR_CNT specifies the number of LRs recorded. The default value is 3. Each LR consumes the memory of sizeof(void *) bytes.
LOS_OMIT_LR_CNT specifies the 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. The reasons for this configuration are as follows:
- LOS_MemAlloc is also called internally.
- LOS_MemAlloc may be encapsulated externally.
- The number of LRs configured by LOS_RECORD_LR_CNT is limited.
Correctly setting this macro can ignore invalid LRs and reduce memory consumption.
Development Guidelines
How to Develop
Memory 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.
The 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.
node size LR[0] LR[1] LR[2]
0x10017320: 0x528 0x9b004eba 0x9b004f60 0x9b005002
0x10017848: 0xe0 0x9b02c24e 0x9b02c246 0x9b008ef0
0x10017928: 0x50 0x9b008ed0 0x9b068902 0x9b0687c4
0x10017978: 0x24 0x9b008ed0 0x9b068924 0x9b0687c4
0x1001799c: 0x30 0x9b02c24e 0x9b02c246 0x9b008ef0
0x100179cc: 0x5c 0x9b02c24e 0x9b02c246 0x9b008ef0
CAUTION Enabling memory leak check affects memory application performance. LR addresses will be recorded for each memory node, increasing memory overhead.
Development Example
This example implements the following:
Call OsMemUsedNodeShow to print information about all nodes.
Simulate a memory leak by requesting memory without releasing it.
Call OsMemUsedNodeShow to print information about all nodes.
Compare the logs to obtain information about the node where a memory leak occurred.
Locate the code based on the LR address.
Sample Code
You can compile and verify the sample code in kernel/liteos_a/testsuites/kernel/src/osTest.c. The MemLeakTest() function is called in TestTaskEntry.
In this example, a memory pool is created. To achieve this purpose, you need to define LOSCFG_MEM_MUL_POOL in target_config.h.
The sample code is as follows:
#include <stdio.h>
#include <string.h>
#include "los_memory.h"
#include "los_config.h"
#define TEST_NEW_POOL_SIZE 2000
#define TEST_MALLOC_SIZE 8
void MemLeakTest(void)
{
VOID *pool = NULL;
/* Create a memory pool. */
pool = LOS_MemAlloc(OS_SYS_MEM_ADDR, TEST_NEW_POOL_SIZE);
(VOID)LOS_MemInit(pool, TEST_NEW_POOL_SIZE);
OsMemUsedNodeShow(pool);
void *ptr1 = LOS_MemAlloc(pool, TEST_MALLOC_SIZE);
void *ptr2 = LOS_MemAlloc(pool, TEST_MALLOC_SIZE);
OsMemUsedNodeShow(pool);
/* Release the memory pool. */
(VOID)LOS_MemDeInit(pool);
}
Verification
The log is as follows:
/* Log for the first OsMemUsedNodeShow. Because the memory pool is not allocated, there is no memory node. */
node LR[0] LR[1] LR[2]
/* Log for the second OsMemUsedNodeShow. There are two memory nodes. */
node LR[0] LR[1] LR[2]
0x00402e0d90: 0x004009f040 0x0040037614 0x0040005480
0x00402e0db0: 0x004009f04c 0x0040037614 0x0040005480
The difference between the two logs is as follows. The following memory nodes are suspected to have blocks with a memory leak.
0x00402e0d90: 0x004009f040 0x0040037614 0x0040005480
0x00402e0db0: 0x004009f04c 0x0040037614 0x0040005480
The following is part of the assembly file:
4009f014: 7d 1e a0 e3 mov r1, #2000
4009f018: 00 00 90 e5 ldr r0, [r0]
4009f01c: 67 7a fe eb bl #-398948 <LOS_MemAlloc>
4009f020: 7d 1e a0 e3 mov r1, #2000
4009f024: 00 40 a0 e1 mov r4, r0
4009f028: c7 79 fe eb bl #-399588 <LOS_MemInit>
4009f02c: 04 00 a0 e1 mov r0, r4
4009f030: 43 78 fe eb bl #-401140 <OsMemUsedNodeShow>
4009f034: 04 00 a0 e1 mov r0, r4
4009f038: 08 10 a0 e3 mov r1, #8
4009f03c: 5f 7a fe eb bl #-398980 <LOS_MemAlloc>
4009f040: 04 00 a0 e1 mov r0, r4
4009f044: 08 10 a0 e3 mov r1, #8
4009f048: 5c 7a fe eb bl #-398992 <LOS_MemAlloc>
4009f04c: 04 00 a0 e1 mov r0, r4
4009f050: 3b 78 fe eb bl #-401172 <OsMemUsedNodeShow>
4009f054: 3c 00 9f e5 ldr r0, [pc, #60]
4009f058: 40 b8 fe eb bl #-335616 <dprintf>
4009f05c: 04 00 a0 e1 mov r0, r4
4009f060: 2c 7a fe eb bl #-399184 <LOS_MemDeInit>
The memory node addressed by 0x4009f040 is not released after being allocated in MemLeakTest.
你可能感兴趣的鸿蒙文章
harmony 鸿蒙Kernel Coding Specification
- 所属分类: 后端技术
- 本文标签:
热门推荐
-
2、 - 优质文章
-
3、 gate.io
-
8、 golang
-
9、 openharmony
-
10、 Vue中input框自动聚焦