Memory leak monitoring method and device, electronic equipment and medium

Abstract

The embodiment of the invention discloses a memory leak monitoring method and device, electronic equipment and a medium. When the method is applied to a device to be tested, the method comprises the steps that in the code compiling stage, a function calling path is determined according to the calling relation of all functions in a code and function identification; in the code running stage, memory operation data for a memory and the function calling path are obtained; and sending the memory operation data and the function call path to a server, so that the server performs memory leak monitoring according to the memory operation data and the function call path. According to the scheme, the function calling path is obtained through scanning in the code compiling stage, so that the multi-level memory function calling path is tracked, other tools do not need to be called for scanning, functions do not need to be called for path backtracking, the code operation amount is reduced, and the memory pressure of the to-be-tested equipment is reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a memory leak monitoring method, device, electronic device and medium. Background Art

[0002] Currently, software development based on C / C++ language on embedded Linux systems often encounters the problem of memory leaks. Memory leaks refer to the situation where the memory dynamically requested by software developers is not released or cannot be released for some reason. As the system runs, it will cause serious consequences such as slowing down the program running speed or even system crash.

[0003] At present, some solutions for monitoring memory leaks and tracing causes can only track one layer of function call records. Solutions that can track multiple layers of function call records will introduce more running codes, which will put a greater burden on the memory of the device under test. In addition, when uploading function call records to the server for remote monitoring, the existing technology server needs to parse the address of the information through stack backtracing, which is a relatively complicated step. Summary of the invention

[0004] The embodiments of the present application provide a memory leak monitoring method, apparatus, electronic device and medium to track the multi-layer call path of memory operation functions without excessively increasing the amount of code and the memory burden of the device under test, while simplifying the process of remote monitoring of device memory by the server.

[0005] According to one aspect of the present application, a memory leak monitoring method is provided, which is applied to a device to be tested, and the method includes:

[0006] In the code compilation stage, the function calling path is determined according to the calling relationship and function identification of each function in the code;

[0007] During the code running phase, memory operation data for the memory and the function calling path are obtained;

[0008] The memory operation data and the function call path are sent to a server, so that the server performs memory leak monitoring according to the memory operation data and the function call path.

[0009] According to another aspect of the present application, a memory leak monitoring method is provided, which is applied to a server, and the method includes:

[0010] Receive memory operation data and function call path sent by the device under test; wherein the memory operation function and the function call path are acquired by the device under test during the code running stage, and the function call path is determined by the device under test during the code compiling stage according to the calling relationship and function identifier of each function in the code;

[0011] Memory leak monitoring is performed based on the memory operation data and the function call path.

[0012] According to one aspect of the present application, a memory leak monitoring device is provided, which is configured on a device to be tested, and the device includes:

[0013] The function call path determination module is used to determine the function call path according to the calling relationship of each function in the code and the function identifier during the code compilation stage;

[0014] A data acquisition module, used to acquire memory operation data for the memory and the function call path during the code running stage;

[0015] The data sending module is used to send the memory operation data and the function calling path to the server, so that the server can perform memory leak monitoring according to the memory operation data and the function calling path.

[0016] According to one aspect of the present application, a memory leak monitoring device is provided, which is configured on a server, and the device includes:

[0017] A data receiving module, used to receive memory operation data and function call path sent by the device under test; wherein the memory operation function and the function call path are acquired by the device under test during the code running stage, and the function call path is determined by the device under test during the code compiling stage according to the calling relationship and function identifier of each function in the code;

[0018] A memory leak monitoring module is used to perform memory leak monitoring based on the memory operation data and the function call path.

[0019] According to another aspect of the present application, an electronic device is provided, the electronic device comprising:

[0020] at least one processor; and

[0021] a memory communicatively connected to at least one processor; wherein,

[0022] The memory stores a computer program that can be executed by at least one processor, and the computer program is executed by at least one processor so that the at least one processor can execute the memory leak monitoring method applied to the device under test of any embodiment of the present application, or execute the memory leak monitoring method applied to the server of any embodiment of the present application.

[0023] According to another aspect of the present application, a computer-readable storage medium is provided, which stores computer instructions, and the computer instructions are used to enable a processor to implement the memory leak monitoring method applied to a device under test according to any embodiment of the present application, or to implement the memory leak monitoring method applied to a server according to any embodiment of the present application when executed.

[0024] The technical solution of the embodiment of the present application, when applied to the device under test, determines the function call path according to the calling relationship and function identification of each function in the code during the code compilation stage; obtains the memory operation data and the function call path for the memory during the code running stage; sends the memory operation data and the function call path to the server, so that the server performs memory leak monitoring according to the memory operation data and the function call path. The above scheme can scan the calling relationship of the function to determine the function call path during the code compilation stage, and can obtain multi-layer call paths without using other tools, meeting the path tracing requirements of memory leak monitoring without increasing the amount of code and the memory pressure of the device under test too much. By obtaining the memory operation data and the function call path during the code running stage and sending them to the server for analysis, timely monitoring of memory leak events and detection of the causes of memory leaks are achieved.

[0025] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0027] Figure 1 It is a flow chart of a method for monitoring memory leaks in a device under test provided according to the first embodiment of the present application;

[0028] Figure 2 It is a flowchart of the code compilation process provided according to the first embodiment of the present application;

[0029] Figure 3 This is a first schematic diagram of a multi-branch tree provided according to Embodiment 1 of the present application;

[0030] Figure 4 is a second schematic diagram of a multi-branch tree provided according to the first embodiment of the present application;

[0031] Figure 5 It is a flowchart of a memory leak monitoring method applied to a device under test provided in accordance with Embodiment 2 of the present application;

[0032] Figure 6 It is a flowchart of a memory leak monitoring method applied to a server provided in Embodiment 3 of the present application;

[0033] Figure 7 is a third schematic diagram of a multi-branch tree provided according to the third embodiment of the present application;

[0034] Figure 8 This is a fourth schematic diagram of a multi-branch tree provided according to the third embodiment of the present application;

[0035] Fig. 9 This is a fifth schematic diagram of a multi-branch tree provided according to the third embodiment of the present application;

[0036] Fig.10 is a sixth schematic diagram of a multi-branch tree provided according to the third embodiment of the present application;

[0037] Fig.11 It is a structural schematic diagram of a memory leak monitoring device configured on a device under test according to a fourth embodiment of the present application;

[0038] Fig.12 It is a structural schematic diagram of a memory leak monitoring device configured on a server according to Embodiment 5 of the present application;

[0039] Fig.13 It is a structural schematic diagram of an electronic device provided according to Embodiment 6 of the present application. DETAILED DESCRIPTION

[0040] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0041] It should be noted that the terms "first", "second", "third", "fourth", "actual", "preset", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0042] Embodiment 1

[0043] Figure 1 A flowchart of a memory leak monitoring method applied to a device under test is provided in the first embodiment of the present application. The embodiment of the present application can be applied to the situation of monitoring memory leak events and analyzing the causes. Typically, it can be applied to the situation of tracing multi-layer function call relationships to analyze the causes of memory leak events. The method can be executed by a memory leak monitoring device, which can be implemented in the form of hardware and / or software, and the memory leak monitoring device can be configured in an electronic device, which can be the device under test. Figure 1 As shown, the method includes:

[0044] S110. In the code compilation stage, the function calling path is determined according to the calling relationship of each function in the code and the function identifier.

[0045] The code compilation stage is performed by the compiler, which processes the source file of the code, including the following three stages: preprocessing, compilation and assembly. The flowchart of the compiler executing the code compilation process is as follows Figure 2 As shown, firstly, the source code is lexically scanned and parsed to obtain a syntax tree. Then semantic analysis is performed to identify semantics and merge syntax trees. Then source code optimization is performed to obtain an intermediate code representation. Then target code generation is performed to obtain target code. Finally, target code optimization is performed to obtain the final target code.

[0046] During the lexical scanning and syntax analysis process in the code compilation stage, the compiler will record the function identifiers corresponding to each function type in the code, but no relationship between the function identifiers is formed, and the calling relationship between the functions is not recorded. In the embodiment of the present application, after the compiler performs lexical scanning and syntax analysis to obtain the function identifiers, it re-scans the calling relationship of the functions in the code, and establishes a function call path based on the calling relationship between the functions with the function identifiers, indicating the calling relationship between the functions, thereby accurately obtaining the calling relationship between multiple layers of functions, which is convenient for subsequent layer-by-layer analysis of the causes of memory leaks.

[0047] In the embodiment of the present application, the function call path can be in the form of a multi-branch tree. For example, assuming that function A calls function B, and function B calls function D, a multi-branch tree can be established such as Figure 3 As shown. Assume that function A calls function B, function B calls function D, and function A also calls function C, and function C calls function D. Then a multi-branch tree can be established as Figure 4 shown.

[0048] The function call path may also be in the form of a string, for example, in the form of (file name-function identifier-line number)->(file name-function identifier-line number)->..., where the file name is the file name of the file where the function is located, and the line number is the line number of the function in the code.

[0049] The function call path can also be stored in a file for easy transmission and identification by other devices.

[0050] After the function call path is generated, it can be recorded in the main program of the code to obtain the function call path when the code is running.

[0051] S120. During the code running phase, memory operation data for the memory and the function calling path are obtained.

[0052] The code running process is executed by the virtual machine, and the memory operation data represents the data of the memory processing process, such as the memory operation type, memory operation address, memory operation length, etc. The memory operation type includes memory application and memory release. When the virtual machine runs the code, it executes the function call process. If there is a memory operation function, the memory operation data can be determined when the memory operation function is executed. In the code running stage, the function call path determined in the code compilation stage can be obtained from the main program of the code.

[0053] S130. Send the memory operation data and the function call path to a server, so that the server performs memory leak monitoring according to the memory operation data and the function call path.

[0054] The server may be a device that can receive and analyze data sent by the device under test. A server can be connected to at least one device under test in communication, so that memory leak monitoring can be performed on multiple devices under test at the same time. The device under test sends memory operation data and function call path to the server. After receiving the memory operation data, the server monitors whether there is a memory leak based on the memory operation data. If there is, the function call process is determined based on the function call path, and then the cause of the memory leak is determined.

[0055] In an embodiment of the present application, obtaining memory operation data for the memory and the function call path includes:

[0056] The function call path is passed into a custom memory operation function, and the custom memory operation function obtains memory operation data;

[0057] Accordingly, sending the memory operation data and the function call path to the server includes:

[0058] The memory operation data and the function call path are sent to the server through the custom memory operation function.

[0059] In an embodiment of the present application, improvements can be made on the basis of the existing memory operation function to obtain a custom memory operation function, which can pass in the string in the main program of the code. Before the code is compiled, the path of the custom memory operation function is found by setting the library load to call the custom memory operation function. Or the linker option of the compiler is used to customize the memory operation function. During the code running stage, the function call path recorded in the main program of the code is passed into the custom memory operation function, and the memory operation data required for executing the custom memory operation function is passed in. The memory operation data and the function call path can be sent directly to the server through the custom memory operation function. This solution requires the memory operation function to be customized so that it can pass in a custom string, that is, it can pass in a function call path in the form of a string. The custom memory operation function itself can obtain the memory operation data and the function call path, without the need to obtain it with the help of other functions, and without increasing the amount of code running too much.

[0060] In an embodiment of the present application, obtaining memory operation data for the memory and the function call path includes:

[0061] In the case where a data acquisition function is inserted after each memory operation function, the memory operation data is acquired from the memory operation function through the data acquisition function;

[0062] Passing the function call path into the data acquisition function;

[0063] Accordingly, sending the memory operation data and the function call path to the server includes:

[0064] The memory operation data and the function call path are sent to the server through the data acquisition function.

[0065] In an embodiment of the present application, it is also possible not to customize the existing memory operation function, but to reconstruct a data acquisition function and insert the data acquisition function after each memory operation function. The memory operation data is obtained from the memory operation function through the data acquisition function, and the function call path is passed to the data acquisition function when the code is running. The data acquisition function obtains the memory operation data and the function call path, and sends the memory operation function and the function call path to the server. This solution does not need to redefine the memory operation function, and can directly call the existing memory operation function, saving the operation of customizing the memory operation function.

[0066] The technical solution of the embodiment of the present application, when applied to the device under test, determines the function call path according to the calling relationship and function identification of each function in the code during the code compilation stage; obtains memory operation data for the memory and the function call path during the code running stage; sends the memory operation data and the function call path to the server, so that the server performs memory leak monitoring according to the memory operation data and the function call path. The above scheme can scan the calling relationship of the function to determine the function call path during the code compilation stage, and can obtain multi-layer call paths without using other tools, meeting the path tracing requirements of memory leak monitoring without increasing the amount of code and the memory pressure of the device under test too much. By obtaining memory operation data and function call paths during the code running stage and sending them to the server for analysis, timely monitoring of memory leak events and tracing the causes of memory leaks are achieved.

[0067] Embodiment 2

[0068] Figure 5 This is a flowchart of a memory leak monitoring method provided in the second embodiment of the present application. The present embodiment is optimized based on the above embodiment. For solutions not described in detail in the present embodiment, see the above embodiment. Figure 5 As shown, the method of the embodiment of the present application specifically includes the following steps:

[0069] S210. In the code compilation stage, after performing lexical scanning and syntax analysis to determine the function identifiers corresponding to different function types, the functions in the code are scanned to determine the calling relationship of the functions corresponding to each function identifier; wherein the level of the calling relationship is determined according to a preset function calling level.

[0070] Among them, lexical scanning and syntax analysis are the processes of the compiler compiling the code, such as the above embodiments and Figure 2 As shown. In the process of lexical scanning and syntax analysis, the function identifiers corresponding to different function types in the code can be determined. Since only the function identifiers are determined in lexical scanning and syntax analysis, but the calling relationship between functions is not determined, the functions in the code are scanned again to determine the calling relationship between functions corresponding to each function identifier.

[0071] The preset function call level can be determined according to the actual situation. For example, too few levels affect the judgment of the call process, and too many levels affect the judgment efficiency. The preset function call level can be set to 6 levels, 8 levels, etc. to meet the user's analysis needs. The preset function call level can be used to determine how many layers of call relationships are obtained after scanning. The preset function call level also determines the length of the function call path.

[0072] S220. Determine a pointing relationship between function identifiers according to the calling relationship, and concatenate the function identifiers based on the pointing relationship to obtain a function calling path.

[0073] In an embodiment of the present application, the pointing relationship between function identifiers can be determined based on the calling relationship between functions. For example, when function A calls function B, it can be determined that the pointing relationship is that function identifier A points to function identifier B. The pointing relationship can be represented by a multi-branch tree structure relationship, for example, from the root node to the leaf node, from the leaf node of the previous layer to the leaf node of the next layer, all of which can represent the pointing relationship. A directional connector that connects character strings can also represent a pointing relationship. Based on the pointing relationship, the function identifiers are concatenated in a form to obtain a function call path. Figure 3 and Figure 4 The function call path in the form of a multi-branch tree, or the function call path in the form of a string: (file name-function identifier-line number)->(file name-function identifier-line number)->…

[0074] In an embodiment of the present application, determining the pointing relationship between the function identifiers according to the calling relationship, and concatenating the function identifiers based on the pointing relationship to obtain a function calling path includes:

[0075] If a memory operation function is scanned, determining a pointing relationship between the first scanned non-memory operation function identifier and the memory operation function identifier according to the calling relationship;

[0076] The non-memory operation function identifier is a function identifier in a call level above the memory operation function; the memory operation function identifier is a function identifier of the memory operation function;

[0077] Based on the pointing relationship, the non-memory operation identifier and the memory operation identifier are concatenated to obtain a function call path.

[0078] Among them, the memory operation function identifier indicates that the type is the identifier of the memory operation function, such as malloc, alloc, realloc, new, free, delete, etc. The non-memory operation function identifier is a function identifier that is at a calling level above the memory operation function and is not a memory operation function. In an embodiment of the present application, during the scanning process, the function starts from the first scanned function and scans along the calling relationship of the function. When the memory operation function is called, the scanning is stopped, and the pointing relationship between the first scanned non-memory operation function identifier and the memory operation function identifier is determined according to the calling relationship. For example, function A calls function B, function B calls function D, function D calls function E, and function E is a memory operation function. Then the scanning is stopped to determine the pointing relationship between the non-memory operation function identifiers A, B, C, D and the memory operation function identifier E. Based on the pointing relationship, the non-memory operation function and the memory operation function are connected in series to obtain a function call path. For example, A->B->C->D->E is obtained by connecting in series, where the pointing relationship of -> represents the calling relationship. If during the scanning process, the scanned call level exceeds the preset function call level and the call to the memory operation function is still not detected, it means that the memory operation function is not called within the call length that the user is concerned about and no memory operation is performed, then the scanning is stopped and the function call path is not further detected.

[0079] In an embodiment of the present application, determining the pointing relationship between the function identifiers according to the calling relationship, and concatenating the function identifiers based on the pointing relationship to obtain a function calling path includes:

[0080] If no memory operation function is scanned, and a third-party library function is scanned, then the pointing relationship between the first scanned local function identifier and the third-party library function identifier is determined according to the calling relationship; wherein the third-party library function is a function without an implementation entity;

[0081] Based on the pointing relationship, the local function identifier and the third-party library function identifier are concatenated to obtain a function call path, and the function call path is saved in a preset file, so that the server can splice the function call path in the preset file with the function call path uploaded by the third-party library; the method for generating the function call path in the third-party library is the same as the method for generating the function call path by the device under test.

[0082] Among them, the local function is a function of an implementation entity in the main program. The preset file can be a file format that the server supports reading, such as a mem.log file. In an embodiment of the present application, it is possible to call a function in a third-party library. When a function without an implementation entity is scanned, it is determined that this function is a third-party library function. In this case, it is necessary to stop scanning, and determine the pointing relationship between the first scanned local function identifier and the third-party library function identifier based on the scanned call relationship. For example, function A calls function B, function B calls function D, function D calls function E, and function E is a third-party library function, then stop scanning, and determine the pointing relationship between local function identifiers A, B, C, D and third-party library function identifier E. Based on the pointing relationship, the local function identifier and the third-party library function identifier are connected in series to obtain a function call path. For example, A->B->C->D->E are obtained by connecting in series, wherein the pointing relationship of -> represents the calling relationship.

[0083] In addition, since the call relationship scanned in the code only reaches the third-party library function, and there are still function call relationships after the third-party library function, and even calls to memory operation functions, the function call path obtained in the main program of the code is incomplete. The function call path can be saved in a preset file, and after the preset file is sent to the server, the server splices the function call path in the preset file with the function call path uploaded by the third-party library to obtain a complete function call path. In the third-party library, the process of code compilation and running is the same as that of the device under test. The function call path is also generated according to the scheme of the above embodiment, sent to the server, and spliced ​​by the server.

[0084] S230. In the code running stage, memory operation data for the memory and the function calling path are obtained.

[0085] S240: Send the memory operation data and the function call path to a server, so that the server performs memory leak monitoring according to the memory operation data and the function call path.

[0086] The embodiment of the present application provides a memory leak monitoring method. In the code compilation stage, after performing lexical scanning and syntax analysis to determine the function identifiers corresponding to different function types, the functions in the code are scanned to determine the calling relationship of the functions corresponding to each function identifier; the pointing relationship between the function identifiers is determined according to the calling relationship, and the function identifiers are connected in series based on the pointing relationship to obtain the function calling path. By scanning the calling relationship between functions in the code compilation stage, and determining the pointing relationship between the function identifiers according to the calling relationship, and forming a function calling path according to the pointing relationship and the function identifier, the problem of increasing the running of a large amount of code and the memory pressure of the device to be tested when performing hierarchical detection through other tools is solved, and the detection of multiple layers of calling relationships can be realized, which improves the efficiency of subsequent tracing of the cause of memory leaks.

[0087] Embodiment 3

[0088] Figure 6 The flowchart of a memory leak monitoring method applied to a server is provided in the third embodiment of the present application. The embodiment of the present application can be applied to the situation of monitoring memory leak events and analyzing the causes. Typically, it can be applied to the situation of tracing multi-layer function call relationships to analyze the causes of memory leak events. The method can be executed by a memory leak monitoring device, which can be implemented in the form of hardware and / or software, and the memory leak monitoring device can be configured in an electronic device, which can be a server. Figure 6 As shown, the method includes:

[0089] S310. Receive memory operation data and a function call path sent by the device under test; wherein the memory operation data and the function call path are acquired by the device under test during a code running phase, and the function call path is determined by the device under test during a code compiling phase according to a calling relationship between functions in the code and a function identifier.

[0090] Exemplarily, the server receives memory operation data and function call path sent by the device under test, wherein the function call path includes: a complete function call path in string form generated when the device under test scans a memory operation function during the code compilation phase, a partial function call path generated when a third-party library function is scanned, and saved in a preset file; a function call path in string form generated when the third-party library scans a memory operation function during the code compilation phase.

[0091] In the embodiment of the present application, after receiving the memory operation data and the function call path sent by the device under test, the method further includes:

[0092] A multi-branch tree structure is established according to the function calling path to represent the function calling path.

[0093] Exemplarily, if the function call path sent by the device under test is a complete function call path, it is in the form of a string. The server can convert the function call path in the form of a string into a multi-branch tree to more vividly and completely represent the call path. For example, for the function call paths A->B->D and A->C->D in the form of strings, it is difficult to vividly represent the relationship between the two function call paths by using two strings to represent the function call paths. A multi-branch tree structure can be established based on the function call path in the form of a string, such as Figure 4 As shown, the calling relationship can be clearly represented. B and C are brother nodes, and both are called by function A.

[0094] In the embodiment of the present application, after receiving the memory operation data and the function call path sent by the device under test, the method further includes:

[0095] If a preset file is received, a multi-branch tree structure is established according to the function call path in the preset file to represent the function call path;

[0096] Matching the last layer leaf nodes of each multi-branch tree with the root node of a third-party multi-branch tree; wherein the third-party multi-branch tree is established according to the function call path uploaded by the third-party library;

[0097] If the match is successful, the target multi-branch tree is determined according to the root node of the last layer of leaf nodes and the last layer of leaf nodes, and the target multi-branch tree is spliced ​​with the third-party multi-branch tree based on the preset function call level to obtain the spliced ​​function call path.

[0098] Exemplarily, if the device under test scans a third-party library function but does not scan a memory operation function during the scanning process in the code compilation phase, the function call path in the main program is saved in a preset file, indicating that this is an incomplete function call path. If the server receives the preset file, it establishes a multi-tree structure according to the function call path in the preset file to represent the function call path, and splices the function call path with the function call path uploaded by the third-party library to obtain a complete function call path. The splicing process is to match the last layer leaf nodes of each multi-tree constructed according to the preset file with the root node of the multi-tree of the third-party library. If they match, the multi-tree is determined based on the last layer leaf nodes and their corresponding root nodes, and the multi-tree is spliced ​​with the multi-tree of the third-party library. For example, suppose the multi-tree in the main program constructed according to the preset file is as follows: Figure 3 As shown in the figure, function D is a third-party library function. Assume that the third-party library multitree is as follows Figure 7The leaf node of the multitree in the main program is D, and the root node of the multitree in the third-party library is D. If they match, the multitree of the main program and the multitree of the third-party library are concatenated to obtain a complete multitree as shown in Figure 8 If the call level in the complete multitree exceeds the preset function call level, the complete multitree is truncated to retain the multitree that meets the preset function call level. For example, assuming that the preset function call level is 4, Figure 8 The multi-branch tree in is intercepted and we get Fig. 9 If F is a memory operation function, then Figure 8 The multi-branch tree in is intercepted and we get Fig.10 The multi-branch tree shown retains the memory operation function to facilitate the cause tracing when a memory leak event is detected later. In the embodiment of the present application, in order to facilitate matching, the last leaf node carrying the root node can be connected to each multi-branch tree in the main program to obtain a single linked list to facilitate matching.

[0099] S320: Perform memory leak monitoring according to the memory operation data and the function call path.

[0100] Exemplarily, the server performs memory leak detection based on memory operation data and function call path, determines whether a memory leak event has occurred based on the memory operation data, and if a memory leak event has occurred, determines the cause of the memory leak event based on the function call path, and traces back to which call link caused the memory leak event.

[0101] In an embodiment of the present application, memory leak monitoring is performed according to the memory operation data and the function call path, including:

[0102] If a memory application operation is detected according to the memory operation data, the memory application operation is recorded; if a memory release operation is detected according to the memory operation data, the recorded memory application operation corresponding to the memory release operation is deleted;

[0103] If the total amount of recorded memory application operations increases, and the number of increases exceeds a preset number, it is determined that a memory leak exists;

[0104] The target function causing the memory leak is determined according to the function calling path.

[0105] Exemplarily, the server detects memory operation data. If a memory application operation is detected according to the memory operation data, the memory application operation is recorded. If a memory release operation is detected, the memory application operation of the memory corresponding to the memory release operation that has been recorded is deleted, and the currently recorded memory application operations are counted. If the total amount of memory application operations increases, and the number of increases exceeds a preset number, it is determined that there is a memory leak. The preset number can be determined according to actual conditions, for example, it can be determined to be 5 times, that is, if it is detected that the memory application operations obtained by counting for 5 consecutive times are all increasing, it is determined that there is a memory leak event. If there is a memory leak event, the cause of the memory leak event can be traced according to the function call path to determine the target function that caused the memory leak.

[0106] The embodiment of the present application provides a memory leak monitoring method, receiving memory operation data and function call path sent by the device under test; wherein the memory operation data and the function call path are obtained by the device under test during the code running stage, and the function call path is determined by the device under test during the code compiling stage according to the calling relationship of each function in the code and the function identifier; memory leak monitoring is performed according to the memory operation data and the function call path. Accurately detect whether a leak has occurred through memory operation data, and accurately locate the calling stage that causes the memory leak according to the function call path generated by scanning in the compiling stage.

[0107] Embodiment 4

[0108] Fig.11 This is a schematic diagram of the structure of a memory leak monitoring device configured on a device under test provided in the fourth embodiment of the present application. The device can execute the memory leak monitoring method provided in any embodiment of the present application and has the corresponding functional modules and beneficial effects of the execution method. Fig.11 As shown, the device comprises:

[0109] The function call path determination module 410 is used to determine the function call path according to the calling relationship and function identifier of each function in the code during the code compilation stage;

[0110] The data acquisition module 420 is used to acquire memory operation data for the memory and the function call path during the code running stage;

[0111] The data sending module 430 is used to send the memory operation data and the function calling path to the server, so that the server performs memory leak monitoring according to the memory operation data and the function calling path.

[0112] In the embodiment of the present application, the function call path determination module 410 includes:

[0113] A calling relationship determination unit, configured to scan the functions in the code and determine the calling relationship of the functions corresponding to the function identifiers after performing lexical scanning and grammatical analysis to determine the function identifiers corresponding to different function types; wherein the level of the calling relationship is determined according to a preset function calling level;

[0114] The series connection unit is used to determine the pointing relationship between the function identifiers according to the calling relationship, and to connect the function identifiers in series based on the pointing relationship to obtain a function calling path.

[0115] In the embodiment of the present application, the series connection unit comprises:

[0116] A first pointing relationship determining subunit is used to determine the pointing relationship between the first scanned non-memory operation function identifier and the memory operation function identifier according to the calling relationship if a memory operation function is scanned;

[0117] The non-memory operation function identifier is a function identifier in a call level above the memory operation function; the memory operation function identifier is a function identifier of the memory operation function;

[0118] The identifier serial connection subunit is used to connect the non-memory operation identifier and the memory operation identifier in series based on the pointing relationship to obtain a function call path.

[0119] In the embodiment of the present application, the series connection unit comprises:

[0120] The second pointing relationship determining subunit is used to determine the pointing relationship between the first scanned local function identifier and the third-party library function identifier according to the calling relationship if the memory operation function is not scanned and the third-party library function is scanned; wherein the third-party library function is a function without an implementation entity;

[0121] A saving subunit is used to concatenate the local function identifier and the third-party library function identifier based on the pointing relationship to obtain a function call path, and save the function call path in a preset file, so that the server can splice the function call path in the preset file with the function call path uploaded by the third-party library; the method for generating the function call path in the third-party library is the same as the method for generating the function call path of the device under test.

[0122] In the embodiment of the present application, the data acquisition module 420 includes:

[0123] An input unit, used for inputting the function call path into a custom memory operation function, and obtaining memory operation data by the custom memory operation function;

[0124] Accordingly, the data sending module 430 includes:

[0125] The first sending unit is used to send the memory operation data and the function call path to the server through the user-defined memory operation function.

[0126] In the embodiment of the present application, the data acquisition module 420 includes:

[0127] An acquisition unit, used for passing the function call path into a custom memory operation function, and obtaining memory operation data by the custom memory operation function;

[0128] Accordingly, the data sending module 430 includes:

[0129] The second sending unit is used to send the memory operation data and the function calling path to the server through the data acquisition function.

[0130] A memory leak monitoring device configured on a device under test provided in an embodiment of the present application can execute a memory leak monitoring method provided in any embodiment of the present application, and has functional modules and beneficial effects corresponding to the execution method.

[0131] Embodiment 5

[0132] Fig.12 This is a schematic diagram of the structure of a memory leak monitoring device configured on a server provided in Embodiment 5 of the present application. The device can execute the memory leak monitoring method provided in any embodiment of the present application and has the corresponding functional modules and beneficial effects of the execution method. Fig.12 As shown, the device comprises:

[0133] The data receiving module 510 is used to receive the memory operation data and the function calling path sent by the device under test; wherein the memory operation function and the function calling path are obtained by the device under test during the code running stage, and the function calling path is determined by the device under test during the code compiling stage according to the calling relationship and function identifier of each function in the code;

[0134] The memory leak monitoring module 520 is used to perform memory leak monitoring according to the memory operation data and the function call path.

[0135] In the embodiment of the present application, the device further includes:

[0136] The multi-branch tree establishment module is used to establish a multi-branch tree structure according to the function call path to represent the function call path.

[0137] In the embodiment of the present application, the device further includes:

[0138] A multi-branch tree reconstruction module, for establishing a multi-branch tree structure to represent the function call path according to the function call path in the preset file if a preset file is received;

[0139] A matching module, used for matching the last layer leaf nodes of each multi-branch tree with the root node of a third-party multi-branch tree; wherein the third-party multi-branch tree is established according to the function call path uploaded by the third-party library;

[0140] The splicing module is used to determine the target multi-branch tree according to the root node of the last layer of leaf nodes and the last layer of leaf nodes if the match is successful, and splice the target multi-branch tree with the third-party multi-branch tree based on a preset function call level to obtain a spliced ​​function call path.

[0141] In the embodiment of the present application, the memory leak monitoring module 520 includes:

[0142] a statistical unit, configured to record a memory application operation if a memory application operation is detected according to the memory operation data, and to delete a recorded memory application operation corresponding to the memory release operation if a memory release operation is detected according to the memory operation data;

[0143] A judgment unit, configured to determine that a memory leak exists if the total amount of recorded memory application operations increases and the number of increases exceeds a preset number;

[0144] The target function determination unit is used to determine the target function that causes the memory leak according to the function call path.

[0145] A memory leak monitoring device configured on a server provided in an embodiment of the present application can execute a memory leak monitoring method provided in any embodiment of the present application, and has functional modules and beneficial effects corresponding to the execution method.

[0146] Embodiment 6

[0147] Fig.13 A schematic diagram of an electronic device 10 that can be used to implement an embodiment of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0148] like Fig.13As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0149] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0150] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a memory leak monitoring method applied to a device under test, or a memory leak monitoring method applied to a server.

[0151] In some embodiments, the memory leak monitoring method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the memory leak monitoring method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the memory leak monitoring method applied to the device under test, or to execute the memory leak monitoring method applied to the server, by any other appropriate means (e.g., by means of firmware).

[0152] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0153] The computer programs for implementing the methods of the present application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable memory leak monitoring device, so that when the computer programs are executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer programs may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0154] In the context of the present application, a computer readable storage medium may be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, device or equipment. A computer readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer readable storage medium may be a machine readable signal medium. A more specific example of a machine readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0155] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0156] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0157] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0158] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the information expected by the technical solution of this application can be achieved, and this document is not limited here.

[0159] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. A memory leak monitoring method, characterized in that: Applied to the device under test, the method comprises: In the code compilation stage, the function calling path is determined according to the calling relationship and function identification of each function in the code; During the code running phase, memory operation data for the memory and the function calling path are obtained; The memory operation data and the function call path are sent to a server, so that the server performs memory leak monitoring according to the memory operation data and the function call path.

2. The method according to claim 1, characterized in that According to the calling relationship and function identifier of each function in the code, determine the function calling path, including: After performing lexical scanning and syntax analysis to determine function identifiers corresponding to different function types, the functions in the code are scanned to determine the calling relationship of the functions corresponding to each function identifier; wherein the level of the calling relationship is determined according to a preset function calling level; The pointing relationship between the function identifiers is determined according to the calling relationship, and the function identifiers are connected in series based on the pointing relationship to obtain a function calling path.

3. The method according to claim 2, characterized in that Determining the pointing relationship between the function identifiers according to the calling relationship, and concatenating the function identifiers based on the pointing relationship to obtain a function calling path, including: If a memory operation function is scanned, determining a pointing relationship between the first scanned non-memory operation function identifier and the memory operation function identifier according to the calling relationship; The non-memory operation function identifier is a function identifier in a call level above the memory operation function; the memory operation function identifier is a function identifier of the memory operation function; Based on the pointing relationship, the non-memory operation identifier and the memory operation identifier are concatenated to obtain a function call path.

4. The method according to claim 2, characterized in that: Determining the pointing relationship between the function identifiers according to the calling relationship, and concatenating the function identifiers based on the pointing relationship to obtain a function calling path, including: If no memory operation function is scanned, and a third-party library function is scanned, then the pointing relationship between the first scanned local function identifier and the third-party library function identifier is determined according to the calling relationship; wherein the third-party library function is a function without an implementation entity; Based on the pointing relationship, the local function identifier and the third-party library function identifier are concatenated to obtain a function call path, and the function call path is saved in a preset file, so that the server can splice the function call path in the preset file with the function call path uploaded by the third-party library; the method for generating the function call path in the third-party library is the same as the method for generating the function call path by the device under test.

5. The method according to claim 1, characterized in that Obtaining memory operation data for the memory and the function call path, including: The function call path is passed into a custom memory operation function, and the custom memory operation function obtains memory operation data; Accordingly, sending the memory operation data and the function call path to the server includes: The memory operation data and the function call path are sent to the server through the custom memory operation function.

6. The method according to claim 1, characterized in that Obtaining memory operation data for the memory and the function call path, including: In the case where a data acquisition function is inserted after each memory operation function, the memory operation data is acquired from the memory operation function through the data acquisition function; Passing the function call path into the data acquisition function; Accordingly, sending the memory operation data and the function call path to the server includes: The memory operation data and the function call path are sent to the server through the data acquisition function.

7. A memory leak monitoring method, characterized in that: Applied to a server, the method comprises: Receive memory operation data and function call path sent by the device under test; wherein the memory operation data and the function call path are acquired by the device under test during the code running stage, and the function call path is determined by the device under test during the code compiling stage according to the calling relationship and function identifier of each function in the code; Memory leak monitoring is performed based on the memory operation data and the function call path.

8. The method according to claim 7, characterized in that After receiving the memory operation data and the function call path sent by the device under test, the method further includes: A multi-branch tree structure is established according to the function calling path to represent the function calling path.

9. The method according to claim 7, characterized in that: After receiving the memory operation data and the function call path sent by the device under test, the method further includes: If a preset file is received, a multi-branch tree structure is established according to the function call path in the preset file to represent the function call path; Matching the last layer leaf nodes of each multi-branch tree with the root node of a third-party multi-branch tree; wherein the third-party multi-branch tree is established according to the function call path uploaded by the third-party library; If the match is successful, the target multi-branch tree is determined according to the root node of the last layer of leaf nodes and the last layer of leaf nodes, and the target multi-branch tree is spliced ​​with the third-party multi-branch tree based on the preset function call level to obtain the spliced ​​function call path.

10. A memory leak monitoring device, characterized in that: Configured on the device to be tested, the device includes: The function call path determination module is used to determine the function call path according to the calling relationship of each function in the code and the function identifier during the code compilation stage; A data acquisition module, used to acquire memory operation data for the memory and the function call path during the code running stage; The data sending module is used to send the memory operation data and the function calling path to the server, so that the server can perform memory leak monitoring according to the memory operation data and the function calling path.

11. A memory leak monitoring device, characterized in that: Configured on a server, the device includes: A data receiving module, used to receive memory operation data and function call path sent by the device under test; wherein the memory operation function and the function call path are acquired by the device under test during the code running stage, and the function call path is determined by the device under test during the code compiling stage according to the calling relationship and function identifier of each function in the code; A memory leak monitoring module is used to perform memory leak monitoring based on the memory operation data and the function call path.

12. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the memory leak monitoring method applied to the device under test as described in any one of claims 1-6, or execute the memory leak monitoring method applied to the server as described in any one of claims 7-9.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which are used to enable a processor to implement the memory leak monitoring method applied to a device under test as described in any one of claims 1-6, or to implement the memory leak monitoring method applied to a server as described in any one of claims 7-9 when executed.

Images