Dynamic memory defect detection method, system and equipment, medium and program product
By constructing a finite state automata to detect dynamic memory defects, the problems of insufficient dynamic memory expansion and neglected memory allocation and release consistency in the existing technology are solved, and cross-platform and scalable memory defect detection is realized.
Patent Information
- Application Number
- CN202411751724.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-02
- Publication Date
- 2025-03-14
AI Technical Summary
The existing memory defect detection scheme has problems such as insufficient dynamic memory scalability and ignoring the consistency of memory allocation and release function use.
By extracting dynamic memory management association information of program languages in different platforms, several types of memory behaviors used for dynamic memory management are determined, and a finite state automaton is built based on these memory behaviors to detect dynamic memory defects in the source code to be detected.
It realizes cross-platform, scalable dynamic memory defect detection, can flexibly adapt to dynamic memory defect detection of different platforms, and overcomes the shortcomings in the existing solutions.
Smart Images

Figure CN119621529A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the technical field of code detection, and in particular to a dynamic memory defect detection method, system, device, medium and program product. Background Art
[0002] With the continuous development of the information age, software systems have gradually become larger, and the functions and structures of software have become increasingly complex and diverse. Millions or even tens of millions of lines of code are common. Some defects are inevitable in the process of software development, so software defect detection and analysis have always been a hot topic in software security research. Once a problem occurs during the operation of code defects, it may have serious consequences for the reliability, functionality, and even security of the software. Therefore, memory defect detection in software code is particularly important.
[0003] However, existing memory defect detection schemes generally have problems such as insufficient dynamic memory scalability and ignoring the consistency of memory allocation and release function usage. Summary of the invention
[0004] The technical problem to be solved by the present disclosure is to overcome the above-mentioned defects in the prior art and to provide a dynamic memory defect detection method, system, device, medium and program product.
[0005] The present invention solves the above technical problems through the following technical solutions:
[0006] The present disclosure provides a method for detecting dynamic memory defects, the detection method comprising:
[0007] Based on the dynamic memory management related information of programming languages in different platforms, several types of memory behaviors used for dynamic memory management are extracted;
[0008] Based on several classes of the memory behaviors, a finite state automaton is constructed to describe the state changes of the memory blocks;
[0009] For a source code to be detected in any platform, obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected;
[0010] The memory behavior sequence is input into the finite state automaton, and a dynamic memory defect situation in the corresponding memory behavior sequence is determined based on an output result.
[0011] Preferably, the step of extracting several types of memory behaviors for dynamic memory management based on dynamic memory management association information of programming languages in different platforms includes:
[0012] Obtaining characteristic information of memory management functions corresponding to the programming languages in different platforms;
[0013] Based on the feature information, several classes of memory behaviors for dynamic memory management are extracted.
[0014] Preferably, some of the several types of memory behaviors belong to the first memory behavior, and the other parts belong to the second memory behavior;
[0015] The characteristics of the first memory behavior are the same in different platforms, and the characteristics of the second memory behavior vary with changes in memory management mechanisms of different platforms.
[0016] Preferably, the memory behavior includes memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior or memory check behavior;
[0017] The memory allocation behavior indicates allocation of a memory block from a heap, the memory reallocation behavior indicates adjustment of the size of an allocated memory block, the memory release behavior indicates release of an allocated memory block, the memory access behavior indicates read and write access to a memory block, and the memory check behavior indicates a check operation on whether the memory allocation is successful;
[0018] The memory access behavior and the memory check behavior belong to the first memory behavior;
[0019] The memory allocation behavior, the memory reallocation behavior, and the memory release behavior belong to the second memory behavior.
[0020] Preferably, the step of constructing a finite state automaton for describing the state change of a memory block based on the memory behaviors of several classes comprises:
[0021] Based on several classes of the memory behaviors, determining several building blocks to form the finite state automaton for describing the state change of a memory block;
[0022] The different building blocks include a state set of a memory block, an input alphabet of an automaton, a state transition function, an initial state, and a final state set;
[0023] The state transfer function is constructed based on each state parameter in the state set of the memory block and each memory behavior in the input alphabet of the automaton that represents the memory behavior causing the state of the memory block to change.
[0024] Preferably, each of the state parameters in the state set of the memory block includes at least two of the following:
[0025] A state indicating that memory has been allocated but not checked, a state indicating that memory has been allocated and checked, a state indicating that memory has been freed, and a state indicating undefined behavior;
[0026] and / or,
[0027] Each of the input alphabets of the automaton represents a memory behavior that causes a change in the state of a memory block, including at least two of the following:
[0028] Memory allocation behavior, memory reallocation behavior, memory access behavior, memory release behavior, and memory empty check behavior;
[0029] and / or,
[0030] The initial state includes a state indicating that memory is not allocated;
[0031] and / or,
[0032] The final state set includes a state indicating that the memory is not allocated or a state indicating that the memory is released.
[0033] Preferably, the step of inputting the memory behavior sequence into the finite state automaton and determining the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result comprises:
[0034] Inputting the memory behavior sequence into the finite state automaton to obtain the automaton state;
[0035] determining, based on the automaton state, whether there is a defect in the memory behavior sequence;
[0036] When it is determined that there is a defect in the memory behavior sequence based on the automaton state, a corresponding memory defect type is determined based on the state transition function.
[0037] Preferably, the step of determining whether there is a defect in the memory behavior sequence based on the automaton state includes:
[0038] In response to the automaton state corresponding to the final state, determining that there is no defect in the memory behavior sequence; otherwise, determining that there is a defect in the memory behavior sequence;
[0039] and / or,
[0040] The step of determining the corresponding memory defect type based on the state transition function when it is determined based on the automaton state that there is a defect in the memory behavior sequence includes:
[0041] When it is determined based on the automaton state that there is a defect in the memory behavior sequence, it is determined that the memory behavior sequence is in an undefined behavior state, and the corresponding memory defect type is determined according to the corresponding state transition situation obtained by the state transition function.
[0042] Preferably, the memory defect types include a memory continued use defect after release, a consistency failure defect, a memory repeated release defect, or a memory unchecked use defect.
[0043] Preferably, before the step of obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected, the method further includes:
[0044] For the memory behavior belonging to the first memory behavior, generating a first recognition rule based on a matched first behavior feature;
[0045] For the memory behavior belonging to the second memory behavior, based on the memory management mechanism of each platform, a preset management operation is used to perform feature expansion to obtain a second identification rule that matches each platform and can identify the second memory behavior;
[0046] The preset management operation is obtained by using the function name of the called function and the parameter definition of the memory allocation size in the program statement.
[0047] Preferably, the step of obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected comprises:
[0048] Acquire a plurality of memory blocks for dynamic allocation in the source code to be detected;
[0049] For each of the memory blocks, a first identification rule is used to extract a first actual memory behavior in the memory block, and a second identification rule is used to extract a second actual memory behavior in the memory block;
[0050] Based on the first actual memory behavior and the second actual memory behavior, the memory behavior sequence corresponding to the memory block is obtained.
[0051] Preferably, the step of obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected comprises:
[0052] Acquire a plurality of memory blocks for dynamic allocation in the source code to be detected;
[0053] Analyze the source code to be detected and generate an abstract syntax tree;
[0054] Based on the abstract syntax tree, construct corresponding preset intermediate representation information;
[0055] The preset intermediate representation information is statically analyzed to obtain the memory behavior sequence of any memory block used for dynamic allocation.
[0056] Preferably, after the step of determining the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result, the method further includes:
[0057] Generate a detection report characterizing the dynamic memory defect situation in the source code to be detected.
[0058] The present disclosure also provides a dynamic memory defect detection system, the detection system comprising:
[0059] A memory behavior extraction module is used to extract several types of memory behaviors used for dynamic memory management based on dynamic memory management related information of programming languages in different platforms;
[0060] An automaton building module, used for building a finite state automaton for describing the state change of a memory block based on several classes of the memory behaviors;
[0061] A behavior sequence acquisition module, used to acquire a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected;
[0062] The defect detection module is used to input the memory behavior sequence into the finite state automaton and determine the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result.
[0063] Preferably, the memory behavior extraction module includes:
[0064] A characteristic information acquisition unit, used to acquire characteristic information of the memory management function corresponding to the program language in different platforms;
[0065] A memory behavior extraction unit is used to extract several types of memory behaviors used for dynamic memory management based on the feature information.
[0066] Preferably, some of the several types of memory behaviors belong to the first memory behavior, and the other parts belong to the second memory behavior;
[0067] The characteristics of the first memory behavior are the same in different platforms, and the characteristics of the second memory behavior vary with changes in memory management mechanisms of different platforms.
[0068] Preferably, the memory behavior includes memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior or memory check behavior;
[0069] The memory allocation behavior indicates allocation of a memory block from a heap, the memory reallocation behavior indicates adjustment of the size of an allocated memory block, the memory release behavior indicates release of an allocated memory block, the memory access behavior indicates read and write access to a memory block, and the memory check behavior indicates a check operation on whether the memory allocation is successful;
[0070] The memory access behavior and the memory check behavior belong to the first memory behavior;
[0071] The memory allocation behavior, the memory reallocation behavior, and the memory release behavior belong to the second memory behavior.
[0072] Preferably, the automaton construction module is used to determine a number of construction parts based on a number of classes of the memory behaviors to form the finite state automaton for describing the state change of the memory block;
[0073] The different building blocks include a state set of a memory block, an input alphabet of an automaton, a state transition function, an initial state, and a final state set;
[0074] The state transfer function is constructed based on each state parameter in the state set of the memory block and each memory behavior in the input alphabet of the automaton that represents the memory behavior causing the state of the memory block to change.
[0075] Preferably, each of the state parameters in the state set of the memory block includes at least two of the following:
[0076] A state indicating that memory has been allocated but not checked, a state indicating that memory has been allocated and checked, a state indicating that memory has been freed, and a state indicating undefined behavior;
[0077] and / or,
[0078] Each of the input alphabets of the automaton represents a memory behavior that causes a change in the state of a memory block, including at least two of the following:
[0079] Memory allocation behavior, memory reallocation behavior, memory access behavior, memory release behavior, and memory empty check behavior;
[0080] and / or,
[0081] The initial state includes a state indicating that memory is not allocated;
[0082] and / or,
[0083] The final state set includes a state indicating that the memory is not allocated or a state indicating that the memory is released.
[0084] Preferably, the defect detection module comprises:
[0085] An automaton state acquisition unit, used for inputting the memory behavior sequence into the finite state automaton to obtain the automaton state;
[0086] a defect detection unit, configured to determine whether there is a defect in the memory behavior sequence based on the automaton state;
[0087] The defect detection unit is further configured to determine a corresponding memory defect type based on the state transition function when it is determined based on the automaton state that there is a defect in the memory behavior sequence.
[0088] Preferably, the defect detection unit is used to determine that there is no defect in the memory behavior sequence in response to the automaton state corresponding to the final state; otherwise, determine that there is a defect in the memory behavior sequence;
[0089] and / or,
[0090] The defect detection unit is used to determine that the memory behavior sequence is in an undefined behavior state when a defect is determined in the memory behavior sequence based on the automaton state, and determine the corresponding memory defect type according to the corresponding state transition situation obtained by the state transition function.
[0091] Preferably, the memory defect types include a memory continued use defect after release, a consistency failure defect, a memory repeated release defect, or a memory unchecked use defect.
[0092] Preferably, the detection system further comprises:
[0093] an identification generation module, configured to generate a first identification rule for the memory behavior belonging to the first memory behavior based on a matched first behavior feature;
[0094] an extension module, configured to perform feature extension on the memory behavior belonging to the second memory behavior by using a preset management operation based on a memory management mechanism of each platform, so as to obtain a second identification rule that matches each platform and can identify the second memory behavior;
[0095] The preset management operation is obtained by using the function name of the called function and the parameter definition of the memory allocation size in the program statement.
[0096] Preferably, the behavior sequence acquisition module includes:
[0097] A memory block acquisition unit, configured to acquire a plurality of memory blocks for dynamic allocation in the source code to be detected based on the first identification rule and the second identification rule; a code analysis unit, configured to analyze the source code to be detected and generate an abstract syntax tree;
[0098] An information construction unit, used to construct corresponding preset intermediate representation information based on the abstract syntax tree;
[0099] The behavior sequence acquisition unit is used to perform static analysis on the preset intermediate representation information to obtain the memory behavior sequence of any memory block used for dynamic allocation.
[0100] Preferably, the detection system further comprises:
[0101] The detection report generation module is used to generate a detection report characterizing the dynamic memory defect situation in the source code to be detected.
[0102] The present disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and used to run on the processor, and the processor implements the above-mentioned dynamic memory defect detection method when executing the computer program.
[0103] The present disclosure also provides a computer-readable storage medium having a computer program stored thereon, and the computer program implements the above-mentioned dynamic memory defect detection method when executed by a processor.
[0104] The present disclosure also provides a computer program product, including a computer program, which implements the above-mentioned dynamic memory defect detection method when executed by a processor.
[0105] On the basis of being in accordance with the common sense in the art, the above-mentioned preferred conditions can be arbitrarily combined to obtain the preferred embodiments of the present disclosure.
[0106] The positive and progressive effects of this disclosure are:
[0107] In the present disclosure, a new cross-platform and scalable dynamic memory defect detection scheme is proposed. Specifically, different memory behaviors for dynamic memory management are determined in advance based on dynamic memory management association information of programming languages of different platforms, and a finite state automaton is constructed based on these memory behaviors. This allows the finite state automaton to be used to quickly and accurately determine whether there are dynamic memory defects, the type of memory defects, etc. for the source code to be detected in any platform. This scheme can flexibly and reliably adapt to dynamic memory defect detection on different platforms, and overcome the problems of insufficient dynamic memory scalability, ignoring the consistency of memory allocation and release function usage, etc. in existing schemes. BRIEF DESCRIPTION OF THE DRAWINGS
[0108] Figure 1 It is a flow chart of a dynamic memory defect detection method according to Embodiment 1 of the present disclosure;
[0109] Figure 2is a first flow chart of a dynamic memory defect detection method according to Embodiment 2 of the present disclosure;
[0110] Figure 3 A second flow chart of the dynamic memory defect detection method according to Embodiment 2 of the present disclosure;
[0111] Figure 4 A third flow chart of the dynamic memory defect detection method according to Embodiment 2 of the present disclosure;
[0112] Figure 5 A fourth flow chart of the dynamic memory defect detection method according to Embodiment 2 of the present disclosure;
[0113] Figure 6 A fifth flow chart of the dynamic memory defect detection method according to Embodiment 2 of the present disclosure;
[0114] Figure 7 A schematic diagram of a source code to be detected in Embodiment 2 of the present disclosure;
[0115] Figure 8 This is a module schematic diagram of a dynamic memory defect detection system according to Embodiment 3 of the present disclosure;
[0116] Fig. 9 This is a module schematic diagram of a dynamic memory defect detection system according to Embodiment 4 of the present disclosure;
[0117] Fig.10 This is a schematic diagram of the structure of an electronic device according to Embodiment 5 of the present disclosure. DETAILED DESCRIPTION
[0118] The present disclosure is further described below by way of examples, but the present disclosure is not limited to the scope of the examples.
[0119] Prefixes such as "first" and "second" are used in the embodiments of the present disclosure only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present disclosure does not constitute a limitation on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary limitation should be constituted due to the use of such prefixes. In addition, in the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.
[0120] At present, most of the dynamic memory defect detection schemes are implemented based on the dynamic memory allocation functions malloc, calloc, realloc and memory release function free under the standard library stdlib.h. Such detection schemes do not have cross-platform characteristics and insufficient scalability, and cannot provide good defect detection support for specific dynamic memory management functions under different platforms; and for the dynamic memory management functions of the C language standard library stdlib.h, there is no consistency defect problem, and all allocated memory blocks are released using the free function, but for memory management functions under other platforms, after using a specific memory allocation function to allocate a memory block, it must be guaranteed to be released using the corresponding memory release function, otherwise the memory will not be released correctly, resulting in memory defects. Based on this, the present disclosure proposes a new cross-platform and scalable dynamic memory defect detection scheme to overcome the problems of insufficient dynamic memory scalability, ignoring the consistency of memory allocation and release function usage, and specifically:
[0121] Example 1
[0122] like Figure 1 As shown, the dynamic memory defect detection method in this embodiment includes:
[0123] S101, extracting several types of memory behaviors for dynamic memory management based on dynamic memory management related information of programming languages in different platforms;
[0124] Among them, the programming language includes but is not limited to C language; by analyzing the characteristics of C language dynamic memory management and use on different platforms, various types of memory behaviors for dynamic memory management are obtained; dynamic management of memory is implemented based on these memory behaviors, but improper use will cause dynamic memory defects.
[0125] For example, several categories of memory behaviors include memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior, and memory check behavior, which are represented by a five-tuple MM=(A, R, F, U, C).
[0126] Specifically, memory allocation behavior A represents allocating a memory block from the heap, memory reallocation behavior R represents adjusting the size of an allocated memory block, memory release behavior F represents releasing an allocated memory block, memory access behavior U represents read and write access to a memory block, and memory check behavior C represents a check operation on whether the memory allocation is successful.
[0127] S102. Based on several types of memory behaviors, construct a finite state automaton for describing the state change of a memory block;
[0128] S103, for a source code to be detected in any platform, obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected;
[0129] S104: Input the memory behavior sequence into a finite state automaton, and determine the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result.
[0130] In this scheme, a new cross-platform and scalable dynamic memory defect detection scheme is proposed. Specifically, by pre-determining the dynamic memory management association information of the programming languages of different platforms, different memory behaviors used for dynamic memory management are determined, and a finite state automaton is constructed based on these memory behaviors. This allows the finite state automaton to be used to quickly and accurately determine whether there are dynamic memory defects, the type of memory defects, etc. for the source code to be detected in any platform. This scheme can flexibly and reliably adapt to dynamic memory defect detection on different platforms, overcoming the problems of insufficient dynamic memory scalability and ignoring the consistency of memory allocation and release function usage in existing schemes.
[0131] Example 2
[0132] The dynamic memory defect detection method in this embodiment is a further improvement of Embodiment 1, specifically:
[0133] In one feasible solution, Figure 2 As shown, step S101 includes:
[0134] S1011, obtaining characteristic information of memory management functions corresponding to programming languages in different platforms;
[0135] S1012. Based on the feature information, extract several types of memory behaviors for dynamic memory management.
[0136] In this scheme, the features of memory management functions of programming languages (such as C language) in different platforms are extracted and analyzed to obtain all memory behaviors required for dynamic memory management. That is, different platforms are considered together to obtain several memory behaviors and then define, set and construct subsequent finite state automata. This ensures the feasibility of cross-platform implementation of the entire detection scheme and the reliability and accuracy of actual defect detection.
[0137] In an implementable solution, a portion of the several types of memory behaviors belong to the first memory behavior, and another portion belongs to the second memory behavior;
[0138] The characteristics of the first memory behavior are the same in different platforms, and the characteristics of the second memory behavior vary with changes in memory management mechanisms of different platforms.
[0139] In this solution, among several types of memory behaviors, some memory behaviors whose characteristics are the same on different platforms and some memory behaviors whose characteristics are different on different platforms are affected by the memory management mechanism of the same platform are further distinguished, so as to facilitate targeted design. In particular, targeted expansion is required for memory behaviors with different cross-platform characteristics, so that the dynamic memory defect detection solution can take into account detection on different platforms.
[0140] In an implementable solution, the memory behavior includes a memory allocation behavior, a memory reallocation behavior, a memory release behavior, a memory access behavior, or a memory check behavior;
[0141] In step S101, several categories of memory behaviors for dynamic memory management are extracted, including at least two of memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior and memory check behavior; preferably, several categories of memory behaviors include five types of memory behaviors: memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior and memory check behavior.
[0142] Among them, memory allocation behavior means allocating a memory block from the heap, memory reallocation behavior means adjusting the size of an allocated memory block, memory release behavior means releasing an allocated memory block, memory access behavior means reading and writing access to a memory block, and memory check behavior means checking whether the memory allocation is successful;
[0143] Memory access behavior and memory check behavior belong to the first memory behavior;
[0144] Memory allocation behavior, memory reallocation behavior, and memory release behavior belong to the second memory behavior.
[0145] In this scheme, the characteristics of memory access behavior U and memory check behavior C are the same on different platforms, while the characteristics of three types of memory behaviors, namely memory allocation behavior A, memory reallocation behavior R, and memory release behavior F, vary according to the specific memory management mechanisms of different platforms.
[0146] Among them, based on these five types of memory behaviors, there are n types of memory management functions: , , ;in, , and A set of memory management functions that need to be used in pairs; that is, when using After allocating memory, you must use the corresponding Reallocate memory and the corresponding Release memory if used and This will result in the inability to properly reallocate and release the allocated memory; that is, a unified system call interface is required. For example, memory requested through malloc must be released using the corresponding memory release function free.
[0147] In one feasible solution, Figure 3 As shown, step S102 includes:
[0148] S1021. Based on several classes of memory behaviors, determine several building blocks to form a finite state automaton for describing a change in a memory block state;
[0149] Among them, the different building blocks include the state set of the memory block, the input alphabet of the automaton, the state transition function, the initial state, and the final state set;
[0150] The state transfer function is constructed based on each state parameter in the state set of the memory block and each memory behavior in the input alphabet of the automaton that represents the memory block state change.
[0151] That is, in the rule-making stage, according to the principle of memory defect generation, the attributes used to describe the dynamic memory allocation and release characteristics are extracted, and based on these attributes, a finite state automaton is established to describe the state changes of memory blocks.
[0152] In an implementable solution, each state parameter in the state set of the memory block includes at least two of the following:
[0153] A state indicating that memory has been allocated but not checked, a state indicating that memory has been allocated and checked, a state indicating that memory has been freed, and a state indicating undefined behavior;
[0154] Each of the input alphabets of the automaton represents a memory action that causes the state of a memory block to change, including at least two of the following:
[0155] Memory allocation behavior, memory reallocation behavior, memory access behavior, memory release behavior, and memory empty check behavior;
[0156] The initial state includes a state indicating that the memory is unallocated;
[0157] The set of final states includes states that indicate that memory is not allocated or states that indicate that memory is released.
[0158] Specifically, a finite state automaton that describes the state changes of memory blocks in dynamic memory management is defined. ;in: is the state set of the memory block, Indicates the state of unallocated memory. Indicates a state where memory has been allocated but not checked. Indicates that the memory has been allocated and checked. Indicates the state where the memory has been released. A state indicating undefined behavior;
[0159] is the input alphabet of the automaton, representing five types of memory behaviors that cause the state of the memory block to change. For memory allocation behavior, and For memory reallocation behavior, To access memory behavior, and To release memory behavior, The behavior of checking whether the memory is empty. is the state transfer function, : ; As the initial state, ; Represents the final state set, including and .
[0160] The state transition table corresponding to the memory state in the finite state automaton is shown in Table 1 below:
[0161] Table 1
[0162]
[0163] In this scheme, through the reasonable setting of the above-mentioned finite state automaton, it is possible to timely and accurately detect whether there are memory defects in the memory behavior sequence of the dynamically allocated memory blocks in any source code to be tested on different platforms, thereby ensuring the feasibility, efficiency and quality of dynamic memory detection.
[0164] In one feasible solution, Figure 4 As shown, step S104 includes:
[0165] S1041, inputting the memory behavior sequence into a finite state automaton to obtain the automaton state;
[0166] S1042, based on the automaton state, determining whether there is a defect in the memory behavior sequence;
[0167] S1043: When it is determined based on the automaton state that there is a defect in the memory behavior sequence, determine a corresponding memory defect type based on the state transition function.
[0168] Memory defect types include memory continued use after release defect, consistency failure defect, memory repeated release defect, or memory unchecked use defect.
[0169] In this solution, the memory behavior sequence of the memory block is input into a finite state automaton to obtain the state of the automaton. Based on the state of the automaton, it is automatically determined whether the input memory behavior sequence has defects, thereby realizing rapid identification of whether dynamic memory in different platforms has defects.
[0170] Once the existence of a defect is determined, the state transfer situation is determined based on the state transfer function to quickly detect the specific type of memory defect that has occurred, thereby ensuring the comprehensiveness and efficiency of dynamic memory defect detection in different platforms.
[0171] In one feasible solution, step S1042 includes:
[0172] In response to the automaton state corresponding to the final state, it is determined that there is no defect in the memory behavior sequence; otherwise, it is determined that there is a defect in the memory behavior sequence;
[0173] Step S1043 includes:
[0174] When it is determined that there is a defect in the memory behavior sequence based on the state of the automaton, it is determined that the memory behavior sequence is in a state of undefined behavior, and the corresponding memory defect type is determined according to the corresponding state transition obtained by the state transition function. In this solution, specifically, when the automaton is finally in the final state, it is determined that there is no dynamic memory defect in the input memory behavior sequence;
[0175] When the automaton is finally in the AUC (i.e., the state where memory is allocated but not checked) or AC (the state where memory is allocated and checked), it is determined that there is a memory non-release defect in the memory behavior sequence of the input;
[0176] When the automaton is finally in the ERR state, based on the state transition when entering the ERR state, it is determined that the following defects exist (combined with the above Table 1):
[0177] when , it is determined that there is a memory use after release defect in the memory behavior sequence of the input;
[0178] when , , , , it is determined that there is a consistency non-satisfaction defect in the memory behavior sequence of the input;
[0179] when , it is determined that there is a memory duplicate release defect in the input memory behavior sequence;
[0180] when , it is determined that there is a memory unchecked use defect in the memory behavior sequence of the input.
[0181] That is, the memory defect rules such as memory not released, memory repeated release, memory continued after release, and undetected dynamic memory use are determined. Through the state transfer function, the final memory state of the automaton is judged, and then the type of memory defect is specifically analyzed to achieve the purpose of quickly and accurately detecting memory defects in dynamic memory.
[0182] In an implementable solution, before step S103, the method further includes:
[0183] For the memory behavior belonging to the first memory behavior, generating a first recognition rule based on the matched first behavior feature;
[0184] Specifically, the characteristics of the memory access behavior U and the memory check behavior C are the same on different platforms.
[0185] Memory access behavior U is the read and write access to the memory block. On different platforms, memory access behavior U is manifested as the use of pointers or arrays. Therefore, for a memory block B used for dynamic allocation, the characteristics of memory access behavior U include: the pointer dereference operator "*" acting on memory block B, the array access symbols "[" and "]" acting on memory block B, and the pointer pointing to memory block B being passed to the library function.
[0186] Memory check behavior C is a check operation to determine whether the memory allocation is successful. On different platforms, memory check behavior C is performed by checking whether the pointer to the memory block returned by the allocation or reallocation behavior is null. Therefore, for a memory block B used for dynamic allocation, the characteristics of memory check behavior C include: a pointer to memory block B, the character NULL, and a relational operator (== or !=).
[0187] For the memory behavior belonging to the second memory behavior, based on the memory management mechanism of each platform, a preset management operation is used to perform feature expansion to obtain a second identification rule that matches each platform and can identify the second memory behavior;
[0188] The preset management operation is obtained by using the function name of the called function and the parameter definition of the memory allocation size in the program statement.
[0189] That is, before memory defect detection, the characteristics of five types of memory behaviors are defined, and the three types of memory behaviors, memory allocation behavior A, memory reallocation behavior R, and memory release behavior F, are expanded according to the specific memory management mechanism in the platform on which the source code to be detected depends, so as to achieve cross-platform identification. .
[0190] In this scheme, based on the characteristics of five types of memory behaviors that are predetermined and expanded, identification rules are used to quickly and accurately identify the corresponding memory behaviors in the source code to be tested across platforms, ensuring the feasibility and efficiency of the entire dynamic memory defect detection.
[0191] Specifically, the three types of memory behaviors, memory allocation behavior A, memory reallocation behavior R, and memory release behavior F, vary according to the specific memory management mechanisms of different platforms and need to be expanded according to specific circumstances. , and They are all a collection of a series of memory management operations op. The characteristics of the memory management operation op are defined by the function name function_name and the memory allocation size parameter size_para. Its syntax is:
[0192] Op::=function_name:size_para
[0193] function_name::=('a'..'z'|'A'..'Z')(('_')?('a'..'z'|'A'..'Z'))*
[0194] size_para::=(none|size=0|size≠0)
[0195] Among them, function_name is represented by a string, size_para has three optional statements, none means that the operation does not need to consider the situation of size_para, and the memory behavior of the operation can be judged based on function_name alone; size=0 and size≠0 indicate that the memory behavior of the operation needs to be judged based on function_name and the size parameter of the function.
[0196] For example, define , , . In Indicates that the operation of calling the malloc function is a memory allocation behavior; In Indicates that calling the realloc function with a non-zero parameter size is a memory reallocation operation; In Indicates that calling the realloc function with the parameter size of 0 is a memory release behavior.
[0197] Therefore, for a dynamically allocated memory block B, the characteristics for identifying memory allocation behavior A, memory reallocation behavior R, and memory release behavior F are:
[0198] Pointer to memory block B, function name function_name and memory allocation size parameter size_para: function_name represents the function name of the called function in the program statement, and size_para represents the parameter in the function representing the memory allocation size.
[0199] Based on the above grammar, the memory behavior characteristics in the platform on which the source code to be detected depends can be expanded, so as to realize cross-platform identification of memory allocation behavior A, memory reallocation behavior R, and memory release behavior F.
[0200] In one feasible solution, Figure 5 As shown, step S103 includes:
[0201] S1031, based on the first identification rule and the second identification rule, obtaining a plurality of memory blocks for dynamic allocation in the source code to be detected;
[0202] S1032, analyzing the source code to be detected and generating an abstract syntax tree;
[0203] S1033. Construct corresponding preset intermediate representation information based on the abstract syntax tree;
[0204] S1034. Perform static analysis on the preset intermediate representation information to obtain a memory behavior sequence of any memory block used for dynamic allocation.
[0205] Specifically, memory blocks B_1, B_2, ..., B_n for dynamic allocation are determined according to the memory allocation behavior in the source code to be detected;
[0206] For each memory block B_i, program static analysis is used to extract the memory behavior sequence L_1, L_2, ..., L_m of the memory block from the source code to be tested. Each memory behavior sequence L_j is a list composed of operations such as a, r, f, u, c, etc.; wherein these operations are extracted from the source code to be tested according to the features of memory behaviors A, R, F, U, C;
[0207] The memory behavior sequence L_1, L_2, ..., L_m corresponding to the memory block B_i is input into a finite state automaton to determine whether there is a dynamic memory defect in the memory behavior sequence based on the finite state automaton; if so, the corresponding dynamic memory defect type and other information are identified and output.
[0208] In the defect detection stage, the source code to be tested is parsed (such as lexical analysis, syntax analysis, etc.) to generate an abstract syntax tree; on this basis, intermediate representation information such as control flow graph and function call graph are constructed; based on these intermediate representation information, symbolic execution technology is used to perform path-sensitive static analysis to achieve the extraction of the memory behavior sequence corresponding to each memory block from the program to be tested.
[0209] Among them, static analysis is a commonly used means of detecting code defects. It performs computational analysis on program status, data propagation and other information statically on the source code instead of executing the target code analysis method. The advantage of static analysis is that it can focus on the code itself and avoid the complex environment required for program operation. At the same time, it uses abstract modeling of the program to simplify complex semantics, which can achieve higher analysis efficiency and coverage. The static analysis method does not rely on program input and operating environment to obtain program inherent attribute information.
[0210] In one feasible solution, Figure 6 As shown, after step S104, the following steps are also included:
[0211] S105: Generate a detection report characterizing dynamic memory defects in the source code to be detected.
[0212] In this solution, after the memory defect detection is completed, the corresponding detection report will be automatically generated directly so that relevant personnel can view and confirm it in time, ensuring the integrity of the entire detection process.
[0213] In the rule-making stage, according to the principles of memory defect generation, attributes used to describe the characteristics of dynamic memory allocation and release are extracted, a finite state automaton is established based on these attributes, and memory defect rules such as non-released memory, repeated memory release, continuation after memory release, and undetected dynamic memory usage are formulated.
[0214] Before defect detection, the characteristics of five types of memory behaviors are defined, and the three types of memory behaviors, namely dynamic memory allocation, reallocation, and release, are expanded according to the specific memory management mechanism in the platform on which the source code to be detected depends.
[0215] In the defect detection phase, the source code to be detected is parsed (such as lexical analysis, syntax analysis, etc.) to generate an abstract syntax tree; on this basis, intermediate representation information such as control flow graph and function call graph are constructed; based on these intermediate representation information, symbolic execution technology is used to perform path-sensitive static analysis to extract the memory behavior sequence corresponding to each memory block from the program to be detected;
[0216] A finite state automaton is used to determine whether a dynamic memory defect exists in the memory behavior sequence. If so, the corresponding dynamic memory defect type is automatically identified. After the entire analysis is completed, a defect detection report is output.
[0217] The implementation process of the dynamic memory defect detection method of this embodiment is described below with reference to specific examples:
[0218] (1) Import the windows.h header file, which contains the memory management functions related to the Windows operating system; Local Alloc is used to allocate a memory block of a specified size in the local heap, and Local Free is used to release the local heap memory block allocated by Local Alloc; Global Alloc is used to allocate a memory block of a specified size in the global heap, and Global Free is used to release the global heap memory block allocated by Global Alloc. Based on the above two types of memory management functions, dynamic memory defect detection rules are formulated;
[0219] (11) The characteristics of the three types of memory behaviors, memory allocation behavior A, memory reallocation behavior R, and memory release behavior F, vary according to the specific memory management mechanism under the Windos platform; when using After allocating memory, you must use the corresponding Reallocate memory and the corresponding Release memory; if you use and If other mismatched functions reallocate and release memory, the reallocation and release will fail, thus affecting other dynamic memory defect detections.
[0220] (12) determining a corresponding memory defect detection rule according to a finite state automaton used to describe a memory block state change;
[0221] (2) The memory access behavior U is an operation that assigns a value through the index Local Alloc, while the memory check behavior C is characterized by HLMem!=null and HGMem!=null under Windows.
[0222] (3) The characteristics of the three types of memory behaviors, memory allocation behavior A, memory reallocation behavior R, and memory release behavior F, are expanded as follows:
[0223]
[0224]
[0225]
[0226]
[0227]
[0228]
[0229]
[0230]
[0231]
[0232] (4) Parse the source code to be tested (such as lexical analysis and syntax analysis) to generate an abstract syntax tree; on this basis, construct intermediate representation information such as control flow graph and function call graph; based on this intermediate representation information, use symbolic execution technology to perform path-sensitive static analysis to extract the memory behavior sequence corresponding to each memory block from the program to be tested;
[0233] (41) For the source code to be tested, a lexical analyzer is used to generate a lexical tokens stream, including identifiers, variables, file names, line and column information, etc. Based on the tokens, a syntax analyzer is used to perform syntax analysis to generate an abstract syntax tree. A multi-level tree structure is used to analyze the hierarchical structure and grammatical relationship of the source code. Each AST node has node type (Decl declaration type, Stmt statement type, Expr expression type, etc.), node attributes (node name, data type, data value, child node, etc.), location information (source file name, line number, column number, etc.), and context information (node scope, context relationship, etc.).
[0234] (42) Traverse the abstract syntax tree, build the program control flow graph and function call graph. When traversing to the if statement, its control flow graph will generate two branches, true and false. When the condition is true, it enters the Local Free (hGMem) statement and then converges at Local Free (hLMem);
[0235] (43) Based on the control flow graph and function call graph, the symbolic execution engine is used to symbolize the nodes in the program, and its symbolic status information is stored in the memory model. Starting from the program entry, different paths are explored to simulate the execution of the program. During the path exploration, the path conditions and constraint information are analyzed to select the path.
[0236] (5) Extract the memory behavior sequence corresponding to each memory block from the source code to be tested, and use a finite state automaton to determine whether the extracted memory behavior sequence has a dynamic memory defect;
[0237] (51) According to the memory allocation behavior characteristics expanded in step (3), match the function call nodes Local Alloc and Global Alloc, and obtain their allocated memory sizes, and determine whether they are ≠0. If the size is 100≠0, obtain the dynamically allocated memory block, which is represented by the symbols hLMem and hGMem;
[0238] (52) For each memory block hLMem or hGMem, extract the memory behavior sequence of the above memory block from the source code to be tested using program static analysis. Figure 7 As shown in the figure, the left side corresponds to the source code to be detected, and the different code lines are marked; there are two paths, namely path one , Path 2: .
[0239] Among them, since the path-sensitive analysis based on symbolic execution is adopted, the condition in line 9 is judged to be true, so that path one is not established, so only the behavior sequence of memory block hLMem or hGMem is extracted from path two.
[0240] Memory behavior sequence of memory block hLMem , a: Local Alloc(LMEM_ZEROINIT,size), u: (int*)hLMem[1], f: Local Free(hLMem).
[0241] Memory behavior sequence of memory block hGMem , a: , f:LocalFree(hGMem).
[0242] (53) The above memory behavior sequence , Input into the finite state automaton;
[0243] For memory behavior sequences , if the state of its memory block hLMem after allocation is , when encountering memory access behavior (int*)hLMem[1], determine the memory behavior sequence An unchecked dynamic memory defect occurred.
[0244] For memory behavior sequences , if the state of its memory block hGMem after allocation is , encountering the dynamic memory release behavior LocalFree, and the memory release behavior corresponding to hGMem , then determine the memory behavior sequence A memory consistency violation occurred.
[0245] (6) After all analyses are completed, a memory defect report is automatically generated for the memory behavior sequence of the memory block in the source code to be tested.
[0246] Example 3
[0247] like Figure 8 As shown, the dynamic memory defect detection system of this embodiment includes:
[0248] A memory behavior extraction module 1 is used to extract several types of memory behaviors used for dynamic memory management based on dynamic memory management related information of programming languages in different platforms;
[0249] The automaton building module 2 is used to build a finite state automaton for describing the state change of a memory block based on several types of memory behaviors;
[0250] The behavior sequence acquisition module 3 is used to acquire the memory behavior sequence of any memory block for dynamic allocation from the source code to be detected in any platform;
[0251] The defect detection module 4 is used to input the memory behavior sequence into the finite state automaton, and determine the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result.
[0252] As for the system embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The system embodiment described above is only illustrative, in which the units described as separate components may or may not be physically separated, and the components as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution.
[0253] Example 4
[0254] like Fig. 9 As shown, the dynamic memory defect detection system in this embodiment is a further improvement of Embodiment 3, specifically:
[0255] In an implementable solution, the memory behavior extraction module 1 includes:
[0256] A characteristic information acquisition unit 5 is used to acquire characteristic information of memory management functions corresponding to programming languages in different platforms;
[0257] The memory behavior extraction unit 6 is used to extract several types of memory behaviors for dynamic memory management based on the feature information.
[0258] In an implementable solution, a portion of the several types of memory behaviors belong to the first memory behavior, and another portion belongs to the second memory behavior;
[0259] The characteristics of the first memory behavior are the same in different platforms, and the characteristics of the second memory behavior vary with changes in memory management mechanisms of different platforms.
[0260] In an implementable solution, the memory behavior includes a memory allocation behavior, a memory reallocation behavior, a memory release behavior, a memory access behavior, or a memory check behavior;
[0261] The memory behavior extraction module extracts several categories of memory behaviors for dynamic memory management, including at least two of memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior and memory check behavior; preferably, the several categories of memory behaviors include five types of memory behaviors: memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior and memory check behavior.
[0262] Among them, memory allocation behavior means allocating a memory block from the heap, memory reallocation behavior means adjusting the size of an allocated memory block, memory release behavior means releasing an allocated memory block, memory access behavior means reading and writing access to a memory block, and memory check behavior means checking whether the memory allocation is successful;
[0263] Memory access behavior and memory check behavior belong to the first memory behavior;
[0264] Memory allocation behavior, memory reallocation behavior, and memory release behavior belong to the second memory behavior.
[0265] In an implementable solution, the automaton construction module 2 is used to determine a number of construction parts based on a number of types of memory behaviors to form a finite state automaton for describing changes in the state of a memory block;
[0266] Among them, the different building blocks include the state set of the memory block, the input alphabet of the automaton, the state transition function, the initial state, and the final state set;
[0267] The state transfer function is constructed based on each state parameter in the state set of the memory block and each memory behavior in the input alphabet of the automaton that represents the memory block state change.
[0268] In an implementable solution, each state parameter in the state set of the memory block includes at least two of the following:
[0269] A state indicating that memory has been allocated but not checked, a state indicating that memory has been allocated and checked, a state indicating that memory has been freed, and a state indicating undefined behavior;
[0270] and / or,
[0271] Each of the input alphabets of the automaton represents a memory action that causes the state of a memory block to change, including at least two of the following:
[0272] Memory allocation behavior, memory reallocation behavior, memory access behavior, memory release behavior, and memory empty check behavior;
[0273] and / or,
[0274] The initial state includes a state indicating that the memory is unallocated;
[0275] and / or,
[0276] The set of final states includes states that indicate that memory is not allocated or states that indicate that memory is released.
[0277] In an implementable solution, the defect detection module 4 includes:
[0278] The automaton state acquisition unit 7 is used to input the memory behavior sequence into the finite state automaton to obtain the automaton state;
[0279] a defect detection unit 8, for determining whether there is a defect in the memory behavior sequence based on the automaton state;
[0280] The defect detection unit 8 is further configured to determine a corresponding memory defect type based on a state transition function when it is determined based on the automaton state that there is a defect in the memory behavior sequence.
[0281] In an operative solution, the defect detection unit 8 is used to determine that there is no defect in the memory behavior sequence in response to the automaton state corresponding to the final state; otherwise, determine that there is a defect in the memory behavior sequence;
[0282] and / or,
[0283] The defect detection unit 8 is used to determine that the memory behavior sequence is in an undefined behavior state when a defect exists in the memory behavior sequence based on the automaton state, and determine the corresponding memory defect type according to the corresponding state transition situation obtained by the state transition function.
[0284] In an implementable solution, the memory defect types include a memory continued use defect after release, a consistency failure defect, a memory repeated release defect, or a memory unchecked use defect.
[0285] In one feasible solution, the detection system further includes:
[0286] An identification generation module 9, configured to generate a first identification rule for a memory behavior belonging to the first memory behavior based on a matched first behavior feature;
[0287] The expansion module 10 is used to perform feature expansion for the memory behavior belonging to the second memory behavior by using a preset management operation based on the memory management mechanism of each platform, so as to obtain a second identification rule that matches each platform and can identify the second memory behavior;
[0288] The preset management operation is obtained by using the function name of the called function and the parameter definition of the memory allocation size in the program statement.
[0289] In an implementable solution, the behavior sequence acquisition module 3 includes:
[0290] A memory block acquisition unit 11 is used to acquire a number of memory blocks for dynamic allocation in the source code to be detected;
[0291] A code analysis unit 12, used to analyze the source code to be detected and generate an abstract syntax tree;
[0292] An information construction unit 13, used to construct corresponding preset intermediate representation information based on the abstract syntax tree;
[0293] The behavior sequence acquisition unit is used to perform static analysis on the preset intermediate representation information to obtain the memory behavior sequence of any memory block used for dynamic allocation.
[0294] In one feasible solution, the detection system further includes:
[0295] The detection report generating module 14 is used to generate a detection report characterizing the dynamic memory defect situation in the source code to be detected.
[0296] As for the system embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The system embodiment described above is only illustrative, in which the units described as separate components may or may not be physically separated, and the components as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution.
[0297] Example 5
[0298] Fig.10 This is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of the present disclosure. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the method in the above embodiment is implemented when the processor executes the program. Fig.10 The electronic device 30 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.
[0299] like Fig.10 As shown, the electronic device 30 may be in the form of a general-purpose computing device, for example, it may be a server device. The components of the electronic device 30 may include, but are not limited to: at least one processor 31, at least one memory 32, and a bus 33 connecting different system components (including the memory 32 and the processor 31).
[0300] The bus 33 includes a data bus, an address bus, and a control bus.
[0301] The memory 32 may include a volatile memory, such as a random access memory (RAM) 321 and / or a cache memory 322 , and may further include a read-only memory (ROM) 323 .
[0302] The memory 32 may also include a program / utility 325 having a set (at least one) of program modules 324, such program modules 324 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.
[0303] The processor 31 executes various functional applications and data processing by running the computer programs stored in the memory 32, such as the method in the above-mentioned embodiment of the present disclosure.
[0304] The electronic device 30 may also communicate with one or more external devices 34 (e.g., keyboards, pointing devices, etc.). Such communication may be performed via an input / output (I / O) interface 35. Furthermore, the model generating device 30 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 36. Fig.10 As shown, the network adapter 36 communicates with other modules of the model-generated device 30 via the bus 33. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the model-generated device 30, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems, etc.
[0305] It should be noted that although several units / modules or sub-units / modules of the electronic device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided into multiple units / modules to be embodied.
[0306] Example 6
[0307] This embodiment provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the steps of the method in the above embodiment are implemented.
[0308] The readable storage medium may include but is not limited to: a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical storage device, a magnetic storage device or any suitable combination of the above.
[0309] Example 7
[0310] This embodiment provides a computer program product, including a computer program. When the computer program is executed by a processor, the method in the above embodiment is implemented.
[0311] Among them, the program code for executing the present disclosure can be written in any combination of one or more programming languages, and the program code can be executed completely on the user device, partially on the user device, as an independent software package, partially on the user device and partially on a remote device, or completely on the remote device.
[0312] Although the specific embodiments of the present disclosure are described above, those skilled in the art should understand that this is only an example, and the protection scope of the present disclosure is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present disclosure, but these changes and modifications all fall within the protection scope of the present disclosure.
Claims
1. A method for detecting dynamic memory defects, characterized in that: The detection method comprises: Based on the dynamic memory management related information of programming languages in different platforms, several types of memory behaviors used for dynamic memory management are extracted; Based on several classes of the memory behaviors, a finite state automaton is constructed to describe the state changes of the memory blocks; For a source code to be detected in any platform, obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected; The memory behavior sequence is input into the finite state automaton, and a dynamic memory defect situation in the corresponding memory behavior sequence is determined based on an output result.
2. The method for detecting dynamic memory defects according to claim 1, wherein: The step of extracting several types of memory behaviors for dynamic memory management based on dynamic memory management association information of programming languages in different platforms includes: Obtaining characteristic information of memory management functions corresponding to the programming languages in different platforms; Based on the feature information, several classes of memory behaviors for dynamic memory management are extracted.
3. The method for detecting dynamic memory defects according to claim 1, wherein: Some of the memory behaviors of the plurality of categories belong to the first memory behavior, and the other parts belong to the second memory behavior; The characteristics of the first memory behavior are the same in different platforms, and the characteristics of the second memory behavior vary with changes in memory management mechanisms of different platforms.
4. The method for detecting dynamic memory defects as claimed in claim 3, characterized in that: The memory behavior includes memory allocation behavior, memory reallocation behavior, memory release behavior, memory access behavior or memory check behavior; The memory allocation behavior indicates allocation of a memory block from a heap, the memory reallocation behavior indicates adjustment of the size of an allocated memory block, the memory release behavior indicates release of an allocated memory block, the memory access behavior indicates read and write access to a memory block, and the memory check behavior indicates a check operation on whether the memory allocation is successful; The memory access behavior and the memory check behavior belong to the first memory behavior; The memory allocation behavior, the memory reallocation behavior, and the memory release behavior belong to the second memory behavior.
5. The method for detecting dynamic memory defects according to any one of claims 1 to 4, characterized in that: The step of constructing a finite state automaton for describing the change of memory block state based on the memory behavior of several classes comprises: Based on several classes of the memory behaviors, determining several building blocks to form the finite state automaton for describing the state change of the memory block; The different building blocks include a state set of a memory block, an input alphabet of an automaton, a state transition function, an initial state, and a final state set; The state transfer function is constructed based on each state parameter in the state set of the memory block and each memory behavior in the input alphabet of the automaton that represents the memory behavior causing the state of the memory block to change.
6. The method for detecting dynamic memory defects as claimed in claim 5, characterized in that: Each of the state parameters in the state set of the memory block includes at least two of the following: A state indicating that memory has been allocated but not checked, a state indicating that memory has been allocated and checked, a state indicating that memory has been freed, and a state indicating undefined behavior; and / or, Each of the input alphabets of the automaton represents a memory behavior that causes a change in the state of a memory block, including at least two of the following: Memory allocation behavior, memory reallocation behavior, memory access behavior, memory release behavior, and memory empty check behavior; and / or, The initial state includes a state indicating that memory is not allocated; and / or, The final state set includes a state indicating that the memory is not allocated or a state indicating that the memory is released.
7. The method for detecting dynamic memory defects according to claim 6, wherein: The step of inputting the memory behavior sequence into the finite state automaton and determining the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result includes: Inputting the memory behavior sequence into the finite state automaton to obtain the automaton state; determining, based on the automaton state, whether there is a defect in the memory behavior sequence; When it is determined that there is a defect in the memory behavior sequence based on the automaton state, a corresponding memory defect type is determined based on the state transition function.
8. The method for detecting dynamic memory defects according to claim 7, wherein: The step of determining whether there is a defect in the memory behavior sequence based on the automaton state comprises: In response to the automaton state corresponding to the final state, determining that there is no defect in the memory behavior sequence; otherwise, determining that there is a defect in the memory behavior sequence; and / or, The step of determining the corresponding memory defect type based on the state transition function when it is determined based on the automaton state that there is a defect in the memory behavior sequence includes: When it is determined based on the automaton state that there is a defect in the memory behavior sequence, it is determined that the memory behavior sequence is in an undefined behavior state, and the corresponding memory defect type is determined according to the corresponding state transition situation obtained by the state transition function.
9. The method for detecting dynamic memory defects as claimed in claim 8, characterized in that: The memory defect types include a memory continued use defect after release, a consistency failure defect, a memory repeated release defect, or a memory unchecked use defect.
10. The method for detecting dynamic memory defects according to any one of claims 1 to 4, characterized in that: Before the step of obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected, the method further includes: For the memory behavior belonging to the first memory behavior, generating a first recognition rule based on a matched first behavior feature; For the memory behavior belonging to the second memory behavior, based on the memory management mechanism of each platform, a preset management operation is used to perform feature expansion to obtain a second identification rule that matches each platform and can identify the second memory behavior; The preset management operation is obtained by using the function name of the called function and the parameter definition of the memory allocation size in the program statement.
11. The method for detecting dynamic memory defects according to claim 10, wherein: The step of obtaining a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected includes: Based on the first identification rule and the second identification rule, obtaining a plurality of memory blocks for dynamic allocation in the source code to be detected; Analyze the source code to be detected and generate an abstract syntax tree; Based on the abstract syntax tree, construct corresponding preset intermediate representation information; The preset intermediate representation information is statically analyzed to obtain the memory behavior sequence of any memory block used for dynamic allocation.
12. The method for detecting dynamic memory defects according to any one of claims 1 to 4, characterized in that: After the step of determining the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result, the method further includes: Generate a detection report characterizing the dynamic memory defect situation in the source code to be detected.
13. A dynamic memory defect detection system, characterized in that: The detection system comprises: A memory behavior extraction module is used to extract several types of memory behaviors used for dynamic memory management based on dynamic memory management related information of programming languages in different platforms; An automaton building module, used for building a finite state automaton for describing the state change of a memory block based on several classes of the memory behaviors; A behavior sequence acquisition module is used to acquire, for a source code to be detected in any platform, a memory behavior sequence of any memory block for dynamic allocation from the source code to be detected; The defect detection module is used to input the memory behavior sequence into the finite state automaton and determine the dynamic memory defect situation in the corresponding memory behavior sequence based on the output result.
14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and used to run on the processor, characterized in that: When the processor executes the computer program, the method for detecting dynamic memory defects described in any one of claims 1 to 12 is implemented.
15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for detecting dynamic memory defects according to any one of claims 1 to 12 is implemented.
16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method for detecting dynamic memory defects according to any one of claims 1 to 12 is implemented.