A method for locating memory leaks in C or C++ language in embedded environment

Abstract

The invention provides a C or C++ language memory leak positioning method in an embedded environment, comprising: S1 ptmalloc modification unit, adding a logic of opening a log file / mnt / dbgmem.txt to a memory initialization function, determining whether to save memory leak information by judging whether there is dbgmem.txt under / mnt; adding writing call time, memory address, memory size, call stack information, allocation function name and number to the log file in memory allocation and release functions, and compiling into a dynamic library; S2 compilation link unit, adding compilation options and link options to Makefile only, using macros to control whether the options are turned on, and recompiling the entire program; S3 running a program to save a log file / mnt / dbgmem.txt unit, saving memory leak related log information in a file in real time instead of a memory; copying the log file to a development environment for analysis; S4 analyzing the log file and outputting a memory leak statistical data unit, analyzing the statistical information of memory leaks within a specified start and end time period; outputting the memory leak statistical information of a specified number of entries for analysis.

Description

Technical Field

[0001] The invention relates to the field of computer application systems, and in particular to a method for locating memory leaks in a C or C++ language in an embedded environment. Background Art

[0002] Embedded software development often meets the growing requirements of functional diversity and reliability under extremely scarce resources due to the contradiction between the requirements of reliability, cost, and power consumption and the requirements of functional diversity and reliability. However, the embedded development language C / C++ leaves memory management to the programmer, which makes it difficult for even the best programmers to avoid memory leaks. Since memory resources in embedded environments are extremely tight, a slightly larger memory leak will cause the program to crash, resulting in the program being too unreliable to be commercialized.

[0003] Currently, there are many tools for finding C / C++ memory leaks. The solutions closest to the present invention include valgrind, dmalloc, etc. Valgrind is a software development tool for memory debugging, memory leak detection and performance analysis. The program can be run in the valgrind environment to monitor the memory usage of the program; dmalloc is a simple and easy-to-use C / C++ memory leak detection tool that can detect the memory in a certain code logic segment or that has not been released until the program ends, and can accurately point out the line number of which source file.

[0004] However, the shortcomings of these existing memory monitoring tools are particularly obvious in complex embedded environments. For example, the valgrind environment consumes a lot of memory, but the memory of embedded systems is already very scarce, which leads to the inability to run because the valgrind itself cannot meet the memory requirements. In addition, valgrind will analyze instructions, but the custom instructions of embedded systems (such as the simd instructions of mips systems, etc.) cannot be analyzed and report errors; for example, dmalloc requires modifying the software source code. Due to the complexity of the software and the large number of source code files, it is often impossible to locate which specific files may have memory leaks, which leads to a large and cumbersome demand for changes and easy introduction of modification errors, especially in customer support and other multi-party cooperation occasions. This is simply impossible to achieve. Secondly, these tools either require a certain logic segment or wait until the program is completed before outputting memory statistics, while most commercial embedded programs have been running without termination, and because some end customers have weak development capabilities and poor overall control of code logic, they cannot find the corresponding logic segment well. Customers only see that the memory is constantly decreasing or OOM program crashes.

[0005] In addition, the commonly used terms in the prior art are as follows:

[0006] Embedded: Embedded systems are application-centric, computer-based systems with customizable hardware and software to meet the strict requirements of application systems for functions, reliability, cost, size, power consumption, etc.

[0007] Memory leak: The dynamically allocated heap memory in the program is not released or cannot be released by the program for some reason, resulting in a waste of system memory, slowing down the program running speed or even causing serious consequences such as system crash;

[0008] Program stack: A storage structure consisting of the order of function calls at the same time.

[0009] PC: Program Counter, a register that stores the execution address of the current program.

[0010] GCC (GNU Compiler Collection) is a set of programming language compilers developed by GNU. It is a set of free software released by GNU compiler collection under GPL and LGPL licenses. It is also a key part of the GNU project and the standard compiler for free Unix-like and Apple Mac OS X operating systems.

[0011] OOM error: Out Of Memory, memory overflow error. After OOM occurs, the Linux kernel will kill the program that uses the most memory and report the OOM error stack information. Summary of the invention

[0012] In order to solve the above problems, this method aims to conveniently and quickly find the source code location of the memory leak on an embedded system with particularly tight memory, so as to provide a starting point for programmers to further analyze the memory leak logic.

[0013] Specifically, the present invention provides a method for locating a memory leak in a C or C++ language in an embedded environment, the method comprising the following steps:

[0014] S1, ptmalloc modification unit, adds the logic of opening the log file / mnt / dbgmem.txt to the memory initialization function, and determines whether to save the memory leak information by judging whether there is dbgmem.txt under / mnt; adds the call time, memory address, memory size, call stack information, allocation function name and number to the log file in the memory allocation and release functions, and compiles it into the dynamic library libdbgmem.so;

[0015] S2, compile and link unit, only add compile options and link options to Makefile, use macros to control whether the options are enabled, and recompile the entire program;

[0016] S3, run the program to save the log file / mnt / dbgmem.txt unit, save the log information related to the memory leak in real time to the file instead of the memory; copy the log file to the development environment for analysis;

[0017] S4, analyzes the log file and outputs the memory leak statistics unit, analyzes the statistical information of the memory leak within the specified start and end time period; outputs the memory leak statistics of the specified number of entries in sequence for further logical analysis.

[0018] Therefore, the advantages of the present application are: memory leak location is achieved without parsing program instructions, modifying program source code, occupying almost no additional memory, affecting program operation, and requiring the program to be terminated. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention.

[0020] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0021] In order to more clearly understand the technical content and advantages of the present invention, the present invention is now further described in detail in conjunction with the accompanying drawings.

[0022] like Figure 1 As shown, a method for locating a memory leak in a C or C++ language in an embedded environment of the present invention comprises the following steps:

[0023] S1, ptmalloc modification unit, adds the logic of opening the log file / mnt / dbgmem.txt to the memory initialization function, and determines whether to save the memory leak information by judging whether there is dbgmem.txt under / mnt; adds the call time, memory address, memory size, call stack information, allocation function name and number to the log file in the memory allocation and release functions, and compiles it into a dynamic library libdbgmem.so, so as to obtain memory allocation and release information without parsing program instructions;

[0024] S2, compile and link unit, only add compile options and link options to Makefile, use macros to control whether the options are enabled, so as to achieve the purpose of not changing the source code and recompile the entire program;

[0025] S3, run the program to save the log file / mnt / dbgmem.txt unit, save the memory leak related log information in real time to the file instead of the memory, so as to achieve the purpose of almost not occupying the memory; copy the log file to the development environment for analysis, so as not to affect the normal operation of the program;

[0026] S4, analyzes the log file and outputs the memory leak statistics unit, analyzes the statistical information of memory leaks within the specified start and end time periods, so as to achieve the purpose of statistically analyzing memory leak information without requiring the code to end; outputs the memory leak statistics of the specified number of entries in sequence for further logical analysis.

[0027] The step S1 further comprises:

[0028] Modify the memory initialization function ptmalloc_init in ptmalloc, memory allocation function: malloc_atfork, public_mALLOc, public_rEALLOc, public_mEMALIGn, public_vALLOc, public_pMEMALIGn, public_cALLOc, public_iCALLOc, public_iCOMALLOc, memory release function: free_atfork, public_fREe.

[0029] Note that the / mnt directory in step S1 can be changed to an SD card mount directory, or an nfs mount directory, or other readable and writable storage space with large space (the size of the space is based on the complexity of the program, the larger the better, and it is recommended to be at least greater than 20MB).

[0030] Adding the compile option and link option in step S2 specifically includes adding the compile option -g-rdynamic, and adding an option corresponding to linking libdbgmem.so in the first link library position.

[0031] The step S3 further includes: executing the command touch dbgmem.txt under / mnt, and then starting the program, the program will automatically write debug information of memory allocation and release in the log file; after the program ends or it is confirmed that the memory leak log information has been collected for a long enough time (the specific length of time is determined by whether it can be fully determined whether a memory leak phenomenon has occurred or an OOM error of a memory leak has occurred), copying / mnt / dbgmem.txt to the development environment.

[0032] The step S4 further includes: calling the analysis program, finding the unmatched allocated memory address according to the allocation and release pair matching principle from the specified start time point to the end time point; and summing the number and size of the unmatched memory addresses according to the same principle as the call stack PC; using the GCC tool addr2line to find the file location corresponding to the unmatched PC.

[0033] The sequential output in step S4 refers to summing the sizes of the unmatched memory addresses and outputting the memory leak statistics of the specified number of entries in a descending order to the programmer for further logic analysis.

[0034] The statistical information includes the arrangement sequence number, the cumulative number of allocations within the statistical time, the cumulative allocation size, the calling PC, the source code file and the number of lines corresponding to the calling PC, so as to provide a starting point for programmers to further analyze the memory leak logic.

[0035] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for locating memory leaks in C or C++ language in an embedded environment, characterized in that: The method comprises the following steps: S1, ptmalloc modification unit, adds the logic of opening the log file / mnt / dbgmem.txt to the memory initialization function, and determines whether to save the memory leak information by judging whether there is dbgmem.txt under / mnt; adds the call time, memory address, memory size, call stack information, allocation function name and number to the log file in the memory allocation and release functions, and compiles it into a dynamic library libdbgmem.so; S2, compile and link unit, only add compile options and link options to Makefile, use macro to control whether the options are turned on, and recompile the entire program; the adding of compile options and link options in step S2 specifically includes adding compile option -g-rdynamic, adding link options corresponding to libdbgmem.so in the first link library position; S3, run the program to save the log file / mnt / dbgmem.txt unit, save the log information related to the memory leak in real time to the file instead of the memory; copy the log file to the development environment for analysis; S4, analyze the log file and output the memory leak statistics unit, analyze the statistical information of the memory leak within the specified start and end time period; output the memory leak statistics of the specified number of entries in sequence for further logical analysis; The step S4 further includes: calling the analysis program, finding the unmatched allocated memory address according to the allocation and release pair matching principle from the specified start time point to the end time point; and summing the number and size of the unmatched memory addresses according to the same principle as the call stack PC; using the GCC tool addr2line to find the file location corresponding to the unmatched PC.

2. The method for locating memory leaks in C or C++ language in an embedded environment according to claim 1, characterized in that: The step S1 further comprises: Modify the memory initialization function ptmalloc_init in ptmalloc, memory allocation function: malloc_atfork, public_mALLOc, public_rEALLOc, public_mEMALIGn, public_vALLOc, public_pMEMALIGn, public_cALLOc, public_iCALLOc, public_iCOMALLOc, memory release function: free_atfork, public_fREe.

3. The method for locating memory leaks in C or C++ language in an embedded environment according to claim 1, characterized in that: In the step S1, the / mnt directory can be changed to an SD card mounting directory, or an nfs mounting directory, or a readable and writable storage space with a large space of more than 20MB.

4. The method for locating memory leaks in C or C++ language in an embedded environment according to claim 1, characterized in that: The step S3 further includes: executing the command touch dbgmem.txt under / mnt, and then starting the program, the program will automatically write debug information of memory allocation and release in the log file; after the program ends or it is confirmed that the memory leak log information has been collected for a long enough time, / mnt / dbgmem.txt is copied to the development environment, and the long enough time is the length of time until it is fully determined that there is a memory leak phenomenon or an OOM error of a memory leak has occurred.

5. The method for locating memory leaks in C or C++ language in an embedded environment according to claim 1, characterized in that: The sequential output refers to summing up the size of the unmatched memory addresses and outputting the memory leak statistics of the specified number of entries in a descending order to the programmer for further logic analysis.

6. The method for locating memory leaks in C or C++ language in an embedded environment according to claim 1, characterized in that: The statistical information includes the sequence number, the cumulative number of allocations within the statistical time, the cumulative allocation size, the call PC, the call The source code file and line number corresponding to PC provide a starting point for programmers to further analyze the memory leak logic.

Images