CN111858290A - Method and apparatus for detecting memory leak path of target code - Google Patents
Method and apparatus for detecting memory leak path of target code Download PDFInfo
- Publication number
- CN111858290A CN111858290A CN201910364845.1A CN201910364845A CN111858290A CN 111858290 A CN111858290 A CN 111858290A CN 201910364845 A CN201910364845 A CN 201910364845A CN 111858290 A CN111858290 A CN 111858290A
- Authority
- CN
- China
- Prior art keywords
- vertex
- target
- point
- memory object
- target memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 61
- 230000006870 function Effects 0.000 claims description 56
- 230000001419 dependent effect Effects 0.000 claims description 29
- 238000004458 analytical method Methods 0.000 claims description 25
- 230000004044 response Effects 0.000 claims description 13
- 230000002441 reversible effect Effects 0.000 claims description 10
- 230000007704 transition Effects 0.000 claims description 10
- 230000003068 static effect Effects 0.000 claims description 9
- 238000012795 verification Methods 0.000 claims description 6
- 230000001902 propagating effect Effects 0.000 claims description 4
- 230000001131 transforming effect Effects 0.000 claims 2
- 238000001514 detection method Methods 0.000 description 29
- 230000008569 process Effects 0.000 description 10
- 238000004590 computer program Methods 0.000 description 7
- 238000010276 construction Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 230000000644 propagated effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000008034 disappearance Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000005206 flow analysis Methods 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 101100498818 Arabidopsis thaliana DDR4 gene Proteins 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
A method and equipment for detecting memory leakage paths of target codes are provided, each using position of a target memory object is used as a vertex, a control flow relation corresponding to each using position is used as a directed edge, a directed graph related to the target memory object is generated according to the vertex and the directed edge, an initial state is set at the vertex of the directed graph corresponding to the using position of a memory application of the target memory object, the initial state of propagation of a trigger characteristic is converted according to the state of each vertex of the directed graph, the path reaching the vertex containing an error state is recorded as a potential memory leakage path, and the potential memory leakage path meeting path implementation conditions is written into a memory leakage path report.
Description
Technical Field
The present application relates to the field of computers, and in particular, to a technique for detecting a memory leakage path of target code.
Background
The memory of the computer is the necessary resource for the software to run. Insufficient memory resources can cause software to run abnormally and even cause system crash and exit. At present, the memory resources used by each software are usually dynamically applied, that is, when the software needs the memory, the software applies to the system, and when the memory is no longer needed, the previously applied memory is released to return to the system. If for some reason the software does not return the memory resources to the system in time, then a memory leak occurs. Especially for software which needs to run for a long time, leaked memory can gradually accumulate along with the lapse of time until all memory resources of the system are exhausted; since the system is generally unable to recover from the memory leak by itself, the memory leak may eventually cause the system to crash and exit.
For the above memory leakage situation, the existing detection methods are dynamic and static. The dynamic detection refers to monitoring a running software system and reporting the memory leakage which occurs, and the detection mode cannot intervene as early as possible in a code development cycle and is not completely covered due to the dependence on an actual running environment; static detection refers to analyzing the running logic of the code and finding out memory leakage points under the condition that software is not running, and can intervene earlier in a code development cycle and the coverage is complete.
The existing static analysis method for memory leakage mainly comprises the following steps:
1) the static analysis technology based on symbolic execution performs memory leak analysis in a mode of simulating program execution, and has the defects that both time and memory complexity are high, and large-scale code cross-function analysis is difficult to analyze and complete in reasonable time (for example, 100 ten thousand lines of codes are analyzed in 4 hours);
2) the static analysis technology based on pattern matching is used for searching memory leakage points in a software system based on a rule defined in advance, and only has a relatively good analysis effect on a modeled pattern, but is ineffective on memory leakage which is not in the pattern;
3) The memory leak detection method based on the sparse value transfer diagram is used for analyzing based on the sparse value transfer diagram, the algorithm complexity is high, and a large-scale software system is difficult to analyze and complete in reasonable time.
Disclosure of Invention
In view of the problems in the prior art, the present application aims to provide a method and apparatus for detecting a memory leak path of target code.
According to an embodiment of the present application, there is provided a method for detecting a memory leak path of target code, the method including:
determining all use positions of the target memory object in the target code;
generating a directed graph about the target memory object in response to each use position of the target memory object as a vertex and a control flow relationship corresponding to each use position as a directed edge;
setting an initial state at a directed graph vertex corresponding to the memory application use point of the target memory object, converting the initial state of trigger characteristic propagation according to the state of each vertex of the directed graph, and recording a path reaching the vertex containing an error state as a potential memory leakage path; and
And verifying the path realizability of all the potential memory leakage paths, and writing the potential memory leakage paths meeting the path realizability condition into a memory leakage path report.
According to an embodiment of the present application, the step of verifying the path realizability performed on all potential memory leakage paths includes:
solving the constraint condition of each potential memory leakage path in all the potential memory leakage paths by using a path constraint solver;
determining a potential memory leakage path with the abandon constraint condition being nonexistent;
the potential memory leak paths that the verification constraint is determined to exist are conditions that satisfy path realizability.
According to an embodiment of the present application, the step of determining all usage locations of the target memory object in the target code includes performing a static pointer analysis of the target memory object to determine all usage locations of the target memory object.
According to an embodiment of the present application, the step of determining all usage positions of the target memory object in the target code includes:
identifying at least one dependent variable in the target code that has a data dependency on a target memory object;
creating a use point for the target memory object in response to at least one first statement in the target code regarding the target memory object and at least one second statement in the target code regarding the dependent variable;
Determining all use positions of the target memory object in the target code, wherein all use positions comprise use points of the target memory object;
wherein the target memory object is used or defined in the first statement and the dependent variable is used or defined in the second statement.
According to an embodiment of the application, the method further comprises:
when the dependent variable is a local variable of a function, creating an end point of the target memory object at the exit position of the function;
wherein the all usage locations include a usage point of the target memory object and an end point of the target memory object.
According to an embodiment of the application, the method further comprises: when the dependent variable is a form parameter of a function, a parameter return point of the target memory object is created at the exit position of the function;
wherein, the all use positions comprise the use point of the target memory object and the parameter return point of the target memory object.
According to an embodiment of the application, the method further comprises: when the branch condition of the statement corresponding to the use point is on the reverse control edge of the statement, creating a branch point related to the branch condition;
Wherein the all usage positions further comprise the branch point.
According to an embodiment of the application, the method further comprises: when the branch condition of the statement corresponding to the end point is on the reverse control edge of the statement, a branch point related to the branch condition is created;
wherein the all usage positions further comprise the branch point.
According to an embodiment of the application, the method further comprises: when the branch condition of the statement corresponding to the parameter return point is on the reverse control edge of the statement, a branch point related to the branch condition is created;
wherein the all usage positions further comprise the branch point.
According to an embodiment of the present application, the step of defining the control flow relationship corresponding to each of the usage positions as a directed edge includes:
performing depth-first search on the control flow graph of the target code, and connecting adjacent vertexes related to the target memory object by a directed edge until the control flow graph is traversed;
recording corresponding branch choices at the outgoing edge of the corresponding vertex of each branch point, wherein the branch choices comprise true or false.
According to an embodiment of the present application, the step of defining the control flow relationship corresponding to each of the usage positions as a directed edge includes:
Creating a first directed edge, wherein the first directed edge points to a use point of a second dependent variable of the target memory object corresponding to a second function from a function call point of the first dependent variable of the target memory object at the first function;
creating a second directed edge, wherein the second directed edge points to a subsequent use point of a first dependent variable of the target memory object at a function call point of the first function from a parameter return point of a second dependent variable of the target memory object at a second function;
wherein the second function is called by the first function.
According to an embodiment of the present application, the step of converting the initial state of the propagation of the triggering characteristic in response to the state of each vertex of the directed graph includes: when the vertex is a state transition trigger vertex, corresponding to the state transition trigger characteristics of the current vertex, storing a corresponding post-transition state in the state set of the vertex, and propagating the post-transition state to the subsequent vertex of the vertex.
According to an embodiment of the present application, the step of converting the initial state of the propagation of the triggering characteristic in response to the state of each vertex of the directed graph includes:
Propagating the state corresponding to the vertex to the successor vertex of the current vertex,
until the directed graph is traversed;
merging the state of each sink at each sink of the directed graph to determine a set of states for each sink.
According to another embodiment of the present application, there is provided an apparatus for detecting a memory leakage path of a target code, wherein the apparatus includes:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to perform the operations of the method described above.
According to yet another embodiment of the present application, there is provided a computer-readable medium storing instructions that, when executed, cause a system to perform the operations of the method described above.
Compared with the prior art, the method and the device determine the data dependence of the pointer by determining all the use positions of the target memory object in the target code, construct the directed graph based on the pointer analysis and the control flow analysis, detect the memory leakage based on the directed graph, have better time and memory complexity than the existing memory leakage detection means, and can simultaneously maintain high precision and high performance particularly when large-scale software is analyzed. In addition, the memory leakage path detection method provided by the application selects the potential memory leakage path by using the low-precision algorithm (flow sensitivity), and then performs path verification by using the high-precision algorithm (path sensitivity) to detect the memory leakage, so that the algorithm efficiency is high.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof with reference to the accompanying drawings.
Fig. 1 illustrates a flow of a method for detecting a memory leakage path according to an embodiment of the present application;
FIG. 2A is a flow chart of a method for detecting a memory leak path of target code according to another embodiment of the present application;
FIGS. 2B-2F illustrate a flow of sub-steps, respectively, of an embodiment of the present application;
FIG. 3 is a usage flow diagram of code in another embodiment of the present application;
FIG. 4 illustrates the construction of a usage flow graph of code in another embodiment of the present application;
FIG. 5 illustrates a state transition pattern using vertices of a flow graph in another embodiment of the present application;
FIG. 6 illustrates an algorithm describing the analysis of state within a function in another embodiment of the present application;
FIG. 7 illustrates a pseudo memory leakage path in another embodiment of the present application;
FIG. 8 illustrates functional modules of an exemplary system that can be used in various embodiments of the present application.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and thus their repetitive description will be omitted.
According to an embodiment of the present application, a method for detecting a memory leak path of target code is provided. Generally speaking, the method takes a target code as input, performs data dependency analysis and control dependency analysis on the target code, constructs a directed Graph, namely a usage-Flow Graph (UFG), performs state analysis on the target code based on the usage-Flow Graph to obtain a potential memory leakage path, verifies the path realizability of the potential memory leakage path to eliminate false alarms, and generates a memory leakage path report based on the potential memory leakage path satisfying the path realizability to output. FIG. 1 illustrates the above flow, where the object code is program intermediate code in some embodiments. Intermediate code (or intermediate language, intermediate code) is here an equivalent internal representation code of the source program that is syntax-oriented and easy to translate into the target program.
The following describes in detail a specific embodiment of the present application, taking a computing device (hereinafter referred to as a detection device) for detecting a memory leak path of target code as an example.
Specifically, referring to fig. 2A, the method includes step S100, step S200, step S300, and step S400.
In step S100, the detection device determines all the use positions of the target memory object in the target code. In some embodiments, there may be multiple different variable names in a program, and some different variable names may in fact point to pointers to the same object. The pointer analysis of the target code is used for analyzing the value of the memory in the program and the object pointed to by the memory, and when the state of one pointer changes, the program analysis algorithm can change the state of the other pointer timely. And performing control flow analysis on the target code for analyzing the control flow in the program to obtain mutual reachability among the statements and a mutual control relationship, which will be developed in detail later.
In step S200, the detection device generates a directed graph related to the target memory object in response to each use position of the target memory object as a vertex and a control flow relationship corresponding to each use position as a directed edge. The directed Graph will be referred to as a usage-Flow Graph (UFG), which is a representation of a data format and program proposed in the present application. To clearly describe this usage flow graph, a piece of exemplary code is given below.
The number at the front of each line in this exemplary code 1 represents the corresponding line number, and the corresponding usage flow graph is shown in fig. 3. The following description is based on code 1 and the usage flow graph. The usage flow graph records the program position where the disappearance event of the variable occurs (the above "usage position") and the control flow relationship between the corresponding variable and other positions where the object is used when the disappearance event occurs. For example, in FIG. 3, "t @ s 9" indicates that the t variable was released by the system on line 9. For a usage flow graph for a certain object, program points which do not use the object are not recorded in the corresponding usage flow graph, for example, for another variable q in the above code, all the usage points are recorded in the usage flow graph for the variable t. The use position of the target memory object includes, but is not limited to, a use point of the target memory object, an end point of a corresponding function, a parameter return point, and the like, and in this example, the use position corresponds to a corresponding line number. The cross-function analysis can be realized by using the flow graph and connecting subgraphs of different methods through edges, such as t @ s3- > p @ s10 and p @ s12- > t @ s6 in FIG. 3.
In step S300, the detection device sets an initial state at a vertex of the directed graph corresponding to the memory application use point of the target memory object, converts the initial state of trigger propagation in response to the state of each vertex of the directed graph, and records a path to a vertex including an error state as a potential memory leakage path. For example, an initial state is set for a vertex, the state is propagated in the usage flow graph plane, if a vertex which can trigger state transition is encountered, the state after the transition is saved in the state set of the vertex, and if an ordinary vertex is encountered, the state is kept unchanged and propagated to the connection point of the vertex, until the usage flow graph is traversed.
In step S400, the detection device verifies the path realizability of all potential memory leak paths, and writes the potential memory leak paths satisfying the path realizability condition into the memory leak path report. The path-implementability algorithm has path-sensitive precision, thereby avoiding false alarm and realizing accurate detection of the memory leakage path.
In some embodiments, referring to fig. 2B, the step of verifying that path realizability is performed on all potential memory leakage paths described above includes substep S410, substep S420, and substep S430. In substep S410, the detection device solves the constraint condition of each of all potential memory leakage paths by using a path constraint solver; in sub-step S420, the detection device determines that the abandon constraint condition is a nonexistent potential memory leak path; in sub-step S430, the device is detected to verify that the potential memory leak path whose constraint is determined to exist is a condition that satisfies path realizability. For example, the system finds one possible memory leak path to be A- > B- > C. For this memory leak path, the constraint condition is a condition that is satisfied by the program executing this path, such as "a ═ 1 and b ═ 2 and c ═ 4 and (e ═ 5 or e ═ 6)"; when this condition can be satisfied, then this path a- > B- > C is said to be realizable or satisfy path realizability. The condition includes a conflict such as "a is 5 and a is 6", and it is obvious that "a is 5 and a is 6" cannot be satisfied, and the constraint condition is said to be unsatisfied and no solution is provided. Here, a solver refers to a tool used to solve constraints, such as Microsoft's Z3 solver.
In some embodiments, in the step of determining all usage locations of the target memory object in the target code, the detection device performs static pointer analysis of the target memory object to determine all usage locations of the target memory object. As described above, there may be multiple different variable names in a program, and some different variable names may in fact point to pointers to the same object. The static pointer analysis is used for analyzing the values of the memory and the objects pointed to by the memory in the program, and when the state of one pointer changes, a program analysis algorithm can timely change the state of the other pointer. The usage location of the target memory object includes, but is not limited to, a usage point of the target memory object, an end point of a corresponding function, a parameter return point, and the like.
In some embodiments, referring to fig. 2C, in the step of determining all the use positions of the target memory object in the target code, the detection device performs substep S110, substep S120, and substep S130. Specifically, in sub-step S110, the detection device identifies at least one dependent variable having a data dependency on the target memory object in the target code; in sub-step S120, the detecting device creates a use point of the target memory object in response to at least one first statement in the target code regarding the target memory object and at least one second statement in the target code regarding the dependent variable; in sub-step S130, the detection device determines all usage locations of the target memory object in the target code, wherein the all usage locations include usage points of the target memory object. For example, for each memory object v, the algorithm first searches all data-dependent v variables in the program (denoted as S (v)). Taking fig. 3 as an example, the variable t has a memory allocation point [ t ═ malloc () ], and since the formal parameter p in the function depends on v, s (v) ═ p }; after all points on which data depends are identified, the construction of points and edges of the usage flow graph can begin. Here, the memory object v is defined or used in the first statement, and the variable in s (v) is defined or used in the second statement.
In addition, in some embodiments, when the dependent variable is a local variable of a function, all the use positions include, in addition to the use point of the target memory object, an end point corresponding to the target memory object; therefore, referring to fig. 2D, the method further includes step S140, in step S140, the detecting device creates an end point of the target memory object at the exit position of the function, for example, when the variable in S (v) is a local variable of the function, the end point of v is created at the exit point of the program.
When the dependent variable is a form parameter of a function, all the use positions comprise a parameter return point corresponding to the target memory object besides the use point of the target memory object; correspondingly, the method further includes step S150, in step S150, the detection device creates a parameter return point of the target memory object at the exit position of the function, for example, when the variable in S (v) is a form parameter of the function, the parameter return point of v is created at the program exit point.
After the creation of the use point, the end point and the parameter return point described above is completed, for each point v @ s already created (where s denotes a program statement), a branch point v @ c is created if the branch condition c is on the reverse control edge (Post-dominance frontier) of s. Specifically, there are three aspects:
(1) When the branch condition of the statement corresponding to the use point is on the reverse control edge of the statement, creating a branch point related to the branch condition;
(2) when the branch condition of the statement corresponding to the end point is on the reverse control edge of the statement, a branch point related to the branch condition is created;
(3) when the branch condition of the statement corresponding to the parameter return point is on the reverse control edge of the statement, a branch point about the branch condition is created.
In all three cases, the branch point obtained by the detection device should be included in the above-mentioned "all use positions".
The creation process of the vertices of the usage flow graph corresponding to the object code is explained above. For object code, it will involve the establishment of an inner edge of a function using a directed edge of the flow graph; using directed edges of a flow graph will also involve the creation of cross-function edges when a cross-function call scenario exists. The construction process of using the directed edge of the flow graph is developed and introduced from the two aspects of the establishment of the inner edge of the function and the establishment of the cross-function edge respectively.
For functional interior edges
When creating the function inner edge, the step of taking the control flow relationship corresponding to each use position as a directed edge as described above with reference to fig. 2E includes sub-step S210 and sub-step S220. In substep S210, the detection device performs depth-first search on the control flow graph of the target code, and connects adjacent vertices related to the target memory object with directed edges until the control flow graph is traversed; in sub-step S220, the detection apparatus records a corresponding branch selection at the outgoing edge of the vertex corresponding to each branch point, wherein the branch selection includes true or false. For example, by performing sequential depth-first search on a control flow graph, we can sequentially traverse each point in the graph, and connect two adjacent points through a directed edge in the traversal process; at the same time, we label the branch choice of the branch on the exit of the branch point (c ═ true or c ═ false).
For cross-function edges
When creating the cross-function edge, the step of taking the control flow relationship corresponding to each use position as the directed edge includes substep S230 and substep S240. In substep S230, the detection device creates a first directed edge, where the first directed edge points to a use point of a second dependent variable of the target memory object corresponding to a second function from a function call point of the first dependent variable of the target memory object at the first function; in sub-step S240, the detecting device creates a second directed edge, where the second directed edge points to a subsequent use point of the first dependent variable of the target memory object at the function call point of the first function from a parameter return point of the second dependent variable of the target memory object at the second function. Wherein the second function is called by the first function.
For clarity, the creation process of function-in and function-across edges will be illustrated below. First, two exemplary pieces of code are given:
Based on the above two pieces of code (code 2 and code 3), for each program function call point CS: r ═ f (…, u, …) (u exists in s (v) and is used as the kth argument of the function call point), two cross-function edges are created:
-edge 1: [ u @ CS ] - > [ pk- > f ] (corresponding to the first directed edge), wherein pk represents the kth formal parameter of the f function (corresponding to the first dependent variable), and code 2 corresponds to the first function, and code 2 calls the function corresponding to code 3, and the formal parameter of the called function corresponds to the second dependent variable;
-edge 2: a return edge [ pk @ end ] - > [ u @ s '] (corresponding to the second directed edge described above), wherein pk @ end represents a parameter return point of the kth formal parameter of the function f, and u @ s' represents a point of use of the variable u immediately after CS (corresponding to the subsequent point of use described above).
The corresponding usage flow graph is shown in fig. 4, where solid arrows represent intra-procedural edges and dashed arrows represent inter-procedural edges.
By this point, the construction of the usage flow graph of the target code is completed, and the detection device can analyze the memory usage condition of the target code based on the usage flow graph. In some embodiments, referring to fig. 2F, the step of converting the initial state of trigger characteristic propagation in response to the state of each vertex of the directed graph described above includes the substep S310. In the sub-step S310, when a vertex is a state transition triggering vertex, the detection device stores a corresponding post-transition state in the state set of the vertex in response to the state transition triggering characteristic of the current vertex, and propagates the post-transition state to the subsequent vertices of the vertex. And when the vertex is triggered by the non-state transition of the vertex, the state of the current vertex is continuously propagated. Thus, the above steps include substep S320 and substep S330. In the substep S320, the detection device propagates the state corresponding to the vertex to a subsequent vertex of the current vertex until the directed graph is traversed; in sub-step S330, the detection device merges the state of each sink at each sink of the directed graph to determine a state set of each sink.
For example, some embodiments describe the usage of system memory using a Finite State Machine (FSM) (see fig. 5). This step uses state analysis to analyze the states of different variables present in the program, the analysis process being based on the use of a flow graph (UFG). Compared with the existing analysis based on the value transfer graph, the state analysis based on the flow graph has the following characteristics:
(1) the life cycle of the whole variable is modeled by using a flow graph, and only the position of the object used in the program is modeled, so that the analysis efficiency is greatly improved;
(2) the existing graph construction algorithm can construct a use flow graph of a program in linear time, so that the graph construction efficiency is greatly improved.
The method for detecting memory leakage based on the finite automatic state machine is to traverse a Usage Flow Graph (UFG) in a cross-function mode, and in the traversing process, a set is used for storing the state of each vertex. Specifically, at the program point of memory application, an a (applied) state is set for the vertex, and then the state is propagated on a Usage Flow Graph (UFG); if a vertex which can trigger state conversion is encountered in the propagation process, the converted state is saved in the state set of the vertex, and for the ordinary vertex, the state is kept unchanged and is propagated to the connection point of the ordinary vertex. At each graph merge point, the states of the different paths are merged. Finally, the system will get the state of the object on each vertex; if an Error (Error) condition exists in the states, the path to the Error point is recorded as a potential memory leak path.
Fig. 6 shows an algorithm describing the case where the state analysis is analyzed within a function. For the above algorithm, table 1 shows the state values of the target object in each step when code 1 (see above) is analyzed.
TABLE 1
If an "E" state (Error) occurs in the last step, the analysis determines that object t is at risk for leakage and records the program path condition for path E.
Specifically, table 1 shows the steps of analyzing code 1 (whose usage flow graph corresponds to fig. 3) based on the usage flow graph. Each column of the table shows the set of states before and after touching a vertex. For example, in conjunction with FIG. 5, at steps 5 and 7, since program points s12 and s7 are control edges where two state sets from different paths meet, a union operation of the sets may be used to merge the two state sets. In step 8, since program point s9 represents the scope boundary of heap object t, state A (allocated) is converted to state E (error), and state F (free) is converted to state X (eXit). Even if state E is obtained via "out of range" operation, the system may report potential memory leak paths. Because some of the potential memory leakage paths based on the use of the flow graph described above are not feasible (infeasible), it is possible to form the spurious memory leakage path shown in fig. 7 (in the direction of the dashed arrow). Thus, to reduce or eliminate false positives, the present application introduces a path-sensitive path-implementability verification algorithm in which potential memory leakage paths derived from the usage flow graph will be later verified. In the path realizability verification process, the detection device will verify the path realizability of the potential memory leak path obtained as described above. The verification algorithm has path sensitive precision, and a constraint solver is used for solving constraint conditions in the path. If a path is determined to be not feasible (infeasible), it is discarded, and if a path is determined to be feasible (feaasible), the entire system considers a memory leakage path and then renders and outputs it to a memory leakage path report.
In fact, on the one hand, the above state analysis only produces a limited number of potential memory leakage paths (since in practice most heap memory space is safely managed), and on the other hand, the constraints of one path often include significant contradictions (e.g., "a and (non a)", as shown in fig. 7, since programmers tend to use direct constraints to satisfy some logical characteristics), so introducing additional path-sensitive path implementation algorithms does not only not increase the cost, but can instead make the process of detecting memory leakage paths more efficient, and in some embodiments can reduce false positives by more than 80%. Therefore, a linear-time solver (linear-time solver) can be first employed to detect some apparently unrealistic constraints, thereby filtering out apparently infeasible paths. For the remaining complex cases, a full-function SMT (Satisfiability module theory) solver (e.g., Z3 solver) is used to perform the solution to check the feasibility of the path. The linear time solver continuously collects the atomicity constraints during the path construction process. Wherein the atomicity constraint is a first order logical formula and does not contain any logical operators like AND, OR, NOT. For example, "a <2 b" and "c" are two atomicity constraints of "(a <2b) and c". If both sets of a path contain the atomicity constraint a, the path must contain "a" and "non-a", and therefore the path does not satisfy the constraint.
The exemplary code corresponding to fig. 7 is as follows:
The present application also provides a computer readable storage medium having stored thereon computer code which, when executed, performs the operations of the method of any of the preceding claims.
The present application also provides a computer program product, which when executed by a computer device, performs the operations of the method as in any one of the preceding claims.
The present application further provides a computer device, comprising:
one or more processors;
a memory for storing one or more computer programs;
the one or more computer programs, when executed by the one or more processors, cause the one or more processors to implement the operations of the method as in any preceding claim.
FIG. 8 illustrates an exemplary electronic device that may be used to implement embodiments described herein.
As shown in fig. 8, in some embodiments, the electronic apparatus 1000 is a computer device for detecting a memory leak path of an object code in the embodiments. In some embodiments, electronic apparatus 1000 includes one or more computer-readable media (e.g., memory or NVM/storage 1020) having instructions and one or more processors (e.g., processor 1005) coupled with the one or more computer-readable media and configured to execute the instructions to implement modules to perform methods described herein.
In one embodiment of the present application, the control module 1010 includes an interface controller to provide an interface to at least one processor 1005 and/or a device or component in communication with the control module 1010.
The control module 1010 may include a memory controller module 1030 to provide an interface to the memory 1015. Memory controller module 1030 includes hardware modules, software modules, and/or firmware modules.
In one embodiment, memory 1015 is used to load and store data and/or instructions for electronic device 1000. In another embodiment, memory 1015 comprises volatile memory, such as DRAM. In some embodiments, memory 1015 comprises a double data rate type four synchronous dynamic random access memory (DDR4 SDRAM).
In one embodiment, control module 1010 includes one or more input/output (I/O) controllers to provide an interface to NVM/storage 1020 and communication interface(s) 1025.
For example, NVM/storage 1020 is used to store data and/or instructions. NVM/storage 1020 includes any suitable non-volatile memory (e.g., flash memory) and/or includes any suitable non-volatile storage device(s) (e.g., one or more Hard Disk drive(s) (HDD (s)), one or more Compact Disc (CD) drive(s), and/or one or more Digital Versatile Disc (DVD) drive (s)).
The NVM/storage 1020 includes storage resources that are physically part of, or accessed by, the device on which the electronic apparatus 1000 is installed, but not necessarily part of the device. For example, NVM/storage 1020 is accessed over a network via communication interface(s) 1025.
Communication interface(s) 1025 provides an interface for electronic apparatus 1000 to communicate over one or more networks and/or with any other suitable device. The electronic device 1000 wirelessly communicates with one or more components of a wireless network according to any of one or more wireless network standards and/or protocols.
In one embodiment, at least one of the processor(s) 1005 is packaged together with logic for one or more controllers (e.g., memory controller module 1030) of the control module 1010. In one embodiment, at least one of the processor(s) 1005 is packaged together with logic for one or more controllers of the control module 1010 to form a System In Package (SiP). In one embodiment, at least one of the processor(s) 1005 is integrated on the same die with logic for one or more controller(s) of the control module 1010. In one embodiment, at least one of the processor(s) 1005 is integrated on the same die with logic of one or more controllers of the control module 1010 to form a system on a chip (SoC).
In various embodiments, the electronic device 1000 includes: a server, a workstation, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet, a netbook, etc.). In various embodiments, electronic device 1000 may have more or fewer components and/or different architectures. For example, in some embodiments, the electronic device 1000 includes one or more cameras, a keyboard, a Liquid Crystal Display (LCD) screen (including a touch screen display), a non-volatile memory port, multiple antennas, a graphics chip, an Application Specific Integrated Circuit (ASIC), and speakers.
It should be noted that the embodiments of the present application are implemented in software and/or a combination of software and hardware, for example, Application Specific Integrated Circuits (ASICs), general purpose computers or any other similar hardware devices. In one embodiment, the software programs of the present application are executed by a processor to implement the steps or functions described above. Also, the software programs (including associated data structures) of the present application are stored in a computer readable recording medium, such as a RAM memory, a magnetic or optical drive or diskette and the like. Additionally, some of the steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.
In addition, some of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application through the operation of the computer. Those skilled in the art will appreciate that the form in which the computer program instructions reside on a computer-readable medium includes, but is not limited to, source files, executable files, installation package files, and the like, and that the manner in which the computer program instructions are executed by a computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Computer-readable media herein can be any available computer-readable storage media or communication media that can be accessed by a computer.
The foregoing is a more detailed description of the present application in connection with specific preferred embodiments and it is not intended that the present application be limited to these specific details. For those skilled in the art to which the present application pertains, several simple deductions or substitutions may be made without departing from the concept of the present application, and all should be considered as belonging to the protection scope of the present application.
Claims (15)
1. A method for detecting a memory leak path of target code, wherein the method comprises the steps of:
determining all use positions of the target memory object in the target code;
generating a directed graph about the target memory object in response to each use position of the target memory object as a vertex and a control flow relationship corresponding to each use position as a directed edge;
setting an initial state at a directed graph vertex corresponding to the memory application use point of the target memory object, converting the initial state of trigger characteristic propagation according to the state of each vertex of the directed graph, and recording a path reaching the vertex containing an error state as a potential memory leakage path; and
and verifying the path realizability of all the potential memory leakage paths, and writing the potential memory leakage paths meeting the path realizability condition into a memory leakage path report.
2. The method of claim 1, wherein the verifying performing path realizability for all potential memory leak paths comprises:
solving the constraint condition of each potential memory leakage path in all the potential memory leakage paths by using a path constraint solver;
Determining a potential memory leakage path with the abandon constraint condition being nonexistent;
the potential memory leak paths that the verification constraint is determined to exist are conditions that satisfy path realizability.
3. The method of claim 1, wherein the determining all usage locations of the target memory object in the target code comprises:
static pointer analysis of a target memory object is performed to determine all usage locations of the target memory object.
4. The method of claim 1, wherein the determining all usage locations of the target memory object in the target code comprises:
identifying at least one dependent variable in the target code that has a data dependency on a target memory object;
creating a use point for the target memory object in response to at least one first statement in the target code regarding the target memory object and at least one second statement in the target code regarding the dependent variable;
determining all use positions of the target memory object in the target code, wherein all use positions comprise use points of the target memory object;
wherein the target memory object is used or defined in the first statement and the dependent variable is used or defined in the second statement.
5. The method of claim 4, wherein the method further comprises:
when the dependent variable is a local variable of a function, creating an end point of the target memory object at the exit position of the function;
wherein the all usage locations include a usage point of the target memory object and an end point of the target memory object.
6. The method of claim 4, wherein the method further comprises:
when the dependent variable is a form parameter of a function, a parameter return point of the target memory object is created at the exit position of the function;
wherein, the all use positions comprise the use point of the target memory object and the parameter return point of the target memory object.
7. The method of claim 4, wherein the method further comprises:
when the branch condition of the statement corresponding to the use point is on the reverse control edge of the statement, creating a branch point related to the branch condition;
wherein the all usage positions further comprise the branch point.
8. The method of claim 5, wherein the method further comprises:
when the branch condition of the statement corresponding to the end point is on the reverse control edge of the statement, a branch point related to the branch condition is created;
Wherein the all usage positions further comprise the branch point.
9. The method of claim 6, wherein the method further comprises:
when the branch condition of the statement corresponding to the parameter return point is on the reverse control edge of the statement, a branch point related to the branch condition is created;
wherein the all usage positions further comprise the branch point.
10. The method according to claim 1, wherein the step of defining the control flow relationship corresponding to each use position as a directed edge comprises:
performing depth-first search on the control flow graph of the target code, and connecting adjacent vertexes related to the target memory object by a directed edge until the control flow graph is traversed;
recording corresponding branch choices at the outgoing edge of the corresponding vertex of each branch point, wherein the branch choices comprise true or false.
11. The method according to claim 1 or 10, wherein the step of defining the control flow relationship corresponding to each use position as a directed edge comprises:
creating a first directed edge, wherein the first directed edge points to a use point of a second dependent variable of the target memory object corresponding to a second function from a function call point of the first dependent variable of the target memory object at the first function;
Creating a second directed edge, wherein the second directed edge points to a subsequent use point of a first dependent variable of the target memory object at a function call point of the first function from a parameter return point of a second dependent variable of the target memory object at a second function;
wherein the second function is called by the first function.
12. The method as claimed in claim 1, wherein said step of transforming said initial state of trigger characteristic propagation in response to the state of each vertex of said directed graph comprises:
when the vertex is a state transition trigger vertex, corresponding to the state transition trigger characteristics of the current vertex, storing a corresponding post-transition state in the state set of the vertex, and propagating the post-transition state to the subsequent vertex of the vertex.
13. The method as claimed in claim 1, wherein said step of transforming said initial state of trigger characteristic propagation in response to the state of each vertex of said directed graph comprises:
propagating the state corresponding to the vertex to the successor vertex of the current vertex,
until the directed graph is traversed;
merging the state of each sink at each sink of the directed graph to determine a set of states for each sink.
14. An apparatus for detecting a memory leakage path of a target code, wherein the apparatus comprises:
a processor; and
a memory arranged to store computer-executable instructions that, when executed, cause the processor to perform operations according to the method of any one of claims 1 to 13.
15. A computer-readable medium storing instructions that, when executed, cause a system to perform operations of any of the methods of claims 1-13.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910364845.1A CN111858290B (en) | 2019-04-30 | 2019-04-30 | Method and apparatus for detecting memory leak path of object code |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910364845.1A CN111858290B (en) | 2019-04-30 | 2019-04-30 | Method and apparatus for detecting memory leak path of object code |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111858290A true CN111858290A (en) | 2020-10-30 |
| CN111858290B CN111858290B (en) | 2024-02-06 |
Family
ID=72965092
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910364845.1A Active CN111858290B (en) | 2019-04-30 | 2019-04-30 | Method and apparatus for detecting memory leak path of object code |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111858290B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113326402A (en) * | 2021-06-16 | 2021-08-31 | 上海哔哩哔哩科技有限公司 | Directed acyclic graph generation method and system |
| CN113326187A (en) * | 2021-05-25 | 2021-08-31 | 扬州大学 | Data-driven intelligent detection method and system for memory leakage |
| CN113535150A (en) * | 2021-07-29 | 2021-10-22 | 北京大学 | Memory leakage-free programming method for DRAM/NVM hybrid memory |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060150168A1 (en) * | 2005-01-04 | 2006-07-06 | International Business Machines Corporation | Annotating graphs to allow quick loading and analysis of very large graphs |
| JP2008282174A (en) * | 2007-05-09 | 2008-11-20 | Matsushita Electric Ind Co Ltd | Information processor, information processing method, and information processing program |
| CN102279804A (en) * | 2011-08-16 | 2011-12-14 | 天津市天祥世联网络科技有限公司 | Memory pool structure of video monitoring platform system and method for implementing memory pool structure |
| CN103440196A (en) * | 2013-07-11 | 2013-12-11 | 大连交通大学 | Resource problem detection method for novel operation system |
| CN104750563A (en) * | 2013-12-26 | 2015-07-01 | 北京大学 | A memory leak auto repair method based on control flow diagram |
| CN105787367A (en) * | 2016-02-23 | 2016-07-20 | 华中科技大学 | Patch security detecting method and system for software update |
| CN107992386A (en) * | 2017-11-23 | 2018-05-04 | 上海斐讯数据通信技术有限公司 | A kind of router memory method for testing pressure and system |
-
2019
- 2019-04-30 CN CN201910364845.1A patent/CN111858290B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060150168A1 (en) * | 2005-01-04 | 2006-07-06 | International Business Machines Corporation | Annotating graphs to allow quick loading and analysis of very large graphs |
| JP2008282174A (en) * | 2007-05-09 | 2008-11-20 | Matsushita Electric Ind Co Ltd | Information processor, information processing method, and information processing program |
| CN102279804A (en) * | 2011-08-16 | 2011-12-14 | 天津市天祥世联网络科技有限公司 | Memory pool structure of video monitoring platform system and method for implementing memory pool structure |
| CN103440196A (en) * | 2013-07-11 | 2013-12-11 | 大连交通大学 | Resource problem detection method for novel operation system |
| CN104750563A (en) * | 2013-12-26 | 2015-07-01 | 北京大学 | A memory leak auto repair method based on control flow diagram |
| CN105787367A (en) * | 2016-02-23 | 2016-07-20 | 华中科技大学 | Patch security detecting method and system for software update |
| CN107992386A (en) * | 2017-11-23 | 2018-05-04 | 上海斐讯数据通信技术有限公司 | A kind of router memory method for testing pressure and system |
Non-Patent Citations (2)
| Title |
|---|
| JACQUES A.PIENAAR等: ""JSWhiz: Static analysis for JavaScript memory leaks"", 《PROCEEDINGS OF THE 2013 IEEE/ACM INTERNATIONAL SYMPOSIUM ON CODE GENERATION AND OPTIMIZATION》, pages 1 - 11 * |
| 陈贝等: ""基于静态检测的C++内存泄漏分析"", 《计算机工程与科学》, pages 118 - 124 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113326187A (en) * | 2021-05-25 | 2021-08-31 | 扬州大学 | Data-driven intelligent detection method and system for memory leakage |
| CN113326187B (en) * | 2021-05-25 | 2023-11-24 | 扬州大学 | Data-driven memory leakage intelligent detection method and system |
| CN113326402A (en) * | 2021-06-16 | 2021-08-31 | 上海哔哩哔哩科技有限公司 | Directed acyclic graph generation method and system |
| CN113535150A (en) * | 2021-07-29 | 2021-10-22 | 北京大学 | Memory leakage-free programming method for DRAM/NVM hybrid memory |
| CN113535150B (en) * | 2021-07-29 | 2023-09-22 | 北京大学 | Programming method for DRAM/NVM hybrid memory without memory leakage |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111858290B (en) | 2024-02-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109426723B (en) | Detection method, system, equipment and storage medium using released memory | |
| US9208057B2 (en) | Efficient model checking technique for finding software defects | |
| US10423518B2 (en) | Systems and methods for analyzing violations of coding rules | |
| US7650595B2 (en) | Sound transaction-based reduction without cycle detection | |
| US8352921B2 (en) | Static analysis defect detection in the presence of virtual function calls | |
| JP2022501734A (en) | How to definitively report a cause and effect in a software system | |
| EP2718820B1 (en) | Identifying and triaging software bugs through backward propagation of under-approximated values and empiric techniques | |
| US20060150160A1 (en) | Software analyzer | |
| CN111858290B (en) | Method and apparatus for detecting memory leak path of object code | |
| US20080028378A1 (en) | Utilizing prior usage data for software build optimization | |
| CN112100072B (en) | Static detection method, device, equipment and medium for application program code | |
| US8578311B1 (en) | Method and system for optimal diameter bounding of designs with complex feed-forward components | |
| US20110145799A1 (en) | Path-sensitive dataflow analysis including path refinement | |
| US10296311B2 (en) | Finding uninitialized variables outside the local scope | |
| US8898649B2 (en) | Application program analysis method, analysis system and recording medium for identifying a contributing factor for an invalid operation of an application program | |
| US10839124B1 (en) | Interactive compilation of software to a hardware language to satisfy formal verification constraints | |
| US9646252B2 (en) | Template clauses based SAT techniques | |
| CN111240987A (en) | Migration program detection method and device, electronic equipment and computer readable storage medium | |
| CN112506806B (en) | Method for debugging program, electronic device and storage medium | |
| CN114817047A (en) | Compiler test method, case generation method and device and instruction storage structure | |
| CN113220302A (en) | Code defect static detection method and system for operating system of Internet of things | |
| Kaestner et al. | Model-driven code generation and analysis | |
| WO2022196219A1 (en) | Program analysis device, program analysis method, and tracing process addition device | |
| KR101225577B1 (en) | Apparatus and method for analyzing assembly language code | |
| US20230021771A1 (en) | Providing metric data for patterns usable in a modeling environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |