Error detection method and device

Abstract

The present application discloses an error detection method and device for improving the accuracy and efficiency of lock-related error detection in a program under test. The method comprises: determining a variable in an intermediate intermediate code of the program under test that is used to represent a thread's holding of a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph comprises a call relationship between functions in the program under test; by traversing the function call graph, determining at least one variable sequence pair, the variable sequence pair comprising two variables; and for each variable sequence pair, mapping each variable in the variable sequence pair to corresponding lock information; based on the lock information corresponding to the variables in the variable sequence pair, determining a lock graph of the processing relationship between locks in the program under test, and based on the lock graph, determining lock-related error information in the program under test.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an error detection method and device. Background Art

[0002] Since blockchain has a wide range of application prospects in security-sensitive fields such as financial services, transportation, and copyright protection, the security of blockchain is of particular concern. Currently, blockchain faces a large number of security threats, such as smart contract vulnerabilities, 51% attacks, double-spending attacks, denial of service attacks, wallet thefts caused by phishing, malicious mining, etc. Due to the decentralized and tamper-proof characteristics of blockchain, and often involving financial and other fields, once a security vulnerability occurs after deployment and operation, its degree of harm and scope of impact are far greater than traditional distributed systems, and the repair of the vulnerability may cause the blockchain to split, greatly increasing the difficulty of repair. Summary of the invention

[0003] The embodiments of the present application provide an error detection method and device for improving the accuracy and efficiency of lock-related error detection in a tested program.

[0004] An error detection method provided in an embodiment of the present application includes:

[0005] Determine a variable in the intermediate code of the program under test that is used to represent the thread's holding of a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph includes a call relationship between functions in the program under test;

[0006] By traversing the function call graph, determining at least one variable sequence pair, the variable sequence pair including two variables; and for each variable sequence pair, mapping each variable in the variable sequence pair to information of a corresponding lock object;

[0007] Based on the information of the lock objects corresponding to the variables in the variable sequence pair, a lock graph of the processing relationship between locks in the program under test is determined, and based on the lock graph, error information related to the locks in the program under test is determined.

[0008] Through this method, variables used to represent thread holding of locks and function call graphs in the intermediate intermediate code of the program under test are determined, and by traversing the function call graph, at least one variable sequence pair is determined, wherein the variable sequence pair includes two variables; and for each variable sequence pair, each variable in the variable sequence pair is respectively mapped to information of a corresponding lock object; based on the information of the lock objects corresponding to the variables in the variable sequence pair, a lock graph of the processing relationship between locks in the program under test is determined, and based on the lock graph, lock-related error information in the program under test is determined, thereby improving the accuracy and efficiency of lock-related error detection in the program under test.

[0009] Optionally, determining at least one variable sequence pair by traversing the function call graph specifically includes:

[0010] The set of the currently surviving variables is determined by traversing the function call graph, and at least one of the variable sequence pairs is determined by using the set of the currently surviving variables.

[0011] Optionally, for each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including:

[0012] For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located;

[0013] Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located.

[0014] Optionally, the mapping relationship is generated in the following manner:

[0015] For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable;

[0016] If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded;

[0017] If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

[0018] Optionally, the lock object of each variable is tracked in the following manner:

[0019] For each of these variables:

[0020] Use the survival statement and end statement of the variable to establish the life cycle of the variable;

[0021] According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable;

[0022] Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

[0023] An error detection device provided in an embodiment of the present application includes:

[0024] The first unit is used to determine variables used to represent the holding of a lock by a thread in the intermediate intermediate code of the program under test, and a function call graph; the variables are variables with a life cycle, and the function call graph includes the calling relationship between functions in the program under test;

[0025] The second unit is configured to determine at least one variable sequence pair by traversing the function call graph, wherein the variable sequence pair includes two variables; and for each variable sequence pair, map each variable in the variable sequence pair to information of a corresponding lock object;

[0026] The third unit is used to determine a lock graph of the processing relationship between locks in the program under test based on information about the lock objects corresponding to the variables in the variable sequence pair, and determine lock-related error information in the program under test based on the lock graph.

[0027] Optionally, determining at least one variable sequence pair by traversing the function call graph specifically includes:

[0028] The set of the currently surviving variables is determined by traversing the function call graph, and at least one of the variable sequence pairs is determined by using the set of the currently surviving variables.

[0029] Optionally, for each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including:

[0030] For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located;

[0031] Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located.

[0032] Optionally, the mapping relationship is generated in the following manner:

[0033] For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable;

[0034] If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded;

[0035] If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

[0036] Optionally, the lock object of each variable is tracked in the following manner:

[0037] For each of these variables:

[0038] Use the survival statement and end statement of the variable to establish the life cycle of the variable;

[0039] According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable;

[0040] Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

[0041] Another embodiment of the present application provides a computing device, which includes a memory and a processor, wherein the memory is used to store program instructions, and the processor is used to call the program instructions stored in the memory, and execute any of the above methods according to the obtained program.

[0042] Furthermore, according to an embodiment, for example, a computer program product for a computer is provided, which includes software code portions, and when the product is run on the computer, these software code portions are used to perform the steps of the method defined above. The computer program product may include a computer-readable medium having the software code portions stored thereon. Furthermore, the computer program product may be directly loaded into the internal memory of the computer and / or sent via a network through at least one of an upload process, a download process, and a push process.

[0043] Another embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable the computer to execute any of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0045] Figure 1 A schematic diagram of a specific process of the Bug detection method provided in the embodiment of the present application;

[0046] Figure 2 A schematic diagram of the workflow of the constraint solver provided in the embodiment of the present application;

[0047] Figure 3 A schematic diagram of the source code of a lock-related blocking bug in the Ethereum blockchain program provided in an embodiment of the present application;

[0048] Figure 4 A schematic diagram of the overall process of the Bug detection method provided in the embodiment of the present application;

[0049] Figure 5 A schematic diagram of the structure of a bug detection device provided in an embodiment of the present application;

[0050] Figure 6 A schematic diagram of the structure of a bug detection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0052] The embodiments of the present application provide an error detection method and device to improve the accuracy and efficiency of lock-related blocking bug detection in a blockchain program written in Rust.

[0053] Among them, the method and the device are based on the same application concept. Since the method and the device solve the problem in a similar principle, the implementation of the device and the method can refer to each other, and the repeated parts will not be repeated.

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

[0055] The following examples and embodiments are to be understood as illustrative examples only. Although this specification may refer to "one", "an" or "some" examples or embodiments in several places, this does not mean that each such reference relates to the same example or embodiment, nor does it mean that the feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. In addition, terms such as "including" and "comprising" should be understood as not limiting the described embodiments to only those features that have been mentioned; such examples and embodiments may also include features, structures, units, modules, etc. that are not specifically mentioned.

[0056] The following is a detailed description of each embodiment of the present application in conjunction with the accompanying drawings. It should be noted that the display order of the embodiments of the present application only represents the order of the embodiments, and does not represent the advantages and disadvantages of the technical solutions provided by the embodiments.

[0057] Terminology explanation:

[0058] Blockchain: Blockchain is a growing list of records (called blocks) connected by cryptography. Each block contains the encrypted hash of the previous block, the corresponding timestamp and transaction information. The distributed ledger connected by blockchain technology allows both parties to effectively record transactions and permanently check the transactions. Blockchain has the advantages of decentralization, openness, autonomy, information immutability, anonymity, etc.

[0059] Rust: As an emerging system programming language, Rust's security and efficiency are the main reasons for its popularity in the blockchain field. Rust's security ensures that there are no memory bugs such as "use after release" and concurrency bugs such as "data competition" in Rust's security code, but it cannot guarantee that there are no blocking bugs in the program.

[0060] Blocking Bugs: Blocking Bugs are bugs that cause one or some threads in a multi-threaded program to be permanently blocked and unable to proceed. Blocking Bugs can cause the blockchain program to be blocked or even crash, causing huge losses to users. In the worst case, attackers can trigger the blocking of a large number of nodes in the entire network by submitting carefully constructed blocks, making 51% attacks possible, thereby shaking the security of the entire blockchain. In the Rust language implementation version of the mainstream blockchain "Ethereum", blocking Bugs account for 67.5% of the total number of Bugs.

[0061] In blockchains written in Rust, blocking bugs mainly include lock-related blocking bugs, and are mainly deadlock bugs.

[0062] Since the characteristics and mechanisms of the Rust language itself are quite different from those of other programming languages ​​such as C, C++, and Java, traditional bug detection tools are difficult to apply to blockchain programs written in Rust. The embodiments of the present application utilize the characteristics and mechanisms of Rust to achieve efficient and accurate bug detection.

[0063] In Rust, each variable has its own lifecycle. When the variable is created, the lifecycle begins; when the lifecycle ends, the variable is automatically released. Rust's lock mechanism relies on the lifecycle mechanism. When a locking instruction (such as mutex.lock()) is executed, a LockGuard object is returned, which represents the holding of the lock. When the LockGuard object's lifecycle ends, the LockGuard object is released, thereby achieving implicit unlocking without the need for an unlock operation.

[0064] Therefore, the embodiment of the present application uses the lifecycle information of the LockGuard object provided by the Rust intermediate intermediate code (MIR) instead of the locking instruction and the unlocking instruction to extract the information of the lock object.

[0065] There is no unlock instruction call in Rust's source code and MIR; in the final underlying code, although there is a call to the unlock instruction at the operating system level, it often takes four to five layers of release function calls to reach it. In order to confirm whether the locking instruction and the unlocking instruction are for the same lock (alias lock), costly and inaccurate inter-procedural alias analysis is required. In the prior art, in order to obtain an alias lock, it is necessary not only to calculate the alias information inside each function, but also to obtain inter-procedural alias analysis information such as the export alias information between functions and the access chain of escaped variables inside the function. The embodiment of the present application only needs to calculate the alias information inside each function (i.e., intra-procedural alias analysis), and with the help of Rust's rich type system, the alias lock can be obtained at a low cost and efficiently.

[0066] In summary, the main purpose of the embodiments of the present application is to provide a blocking bug detection method and tool for blockchain programs written in Rust, specifically involving the detection of blocking bugs related to locks.

[0067] Among them, lock-related blocking bug detection utilizes Rust's unique lock mechanism and lifecycle information, avoiding the inefficient and inaccurate inter-procedural alias detection in traditional methods, and can quickly and accurately build a lock graph, thereby achieving efficient and accurate detection of lock-related blocking bugs.

[0068] The tool provided in the embodiment of the present application can be integrated into the existing compilation tool, so as to efficiently detect the blocking bugs existing in the current mainstream blockchain programs, and accurately report their source code locations and trigger paths, helping developers to locate and fix such bugs during the development and testing stages.

[0069] In the embodiment of the present application, the module used to implement lock-related blocking bug detection is called a lock-related blocking bug static detector. Specific examples are given below.

[0070] Since Rust has no explicit unlocking mechanism, but uses the life cycle of LockGuard to complete implicit automatic unlocking, there is no unlocking statement in the source code and MIR, so it is difficult for traditional deadlock detection algorithms to detect directly on the source code and MIR, and can only rely on the underlying code (such as LLVM IR, assembly, etc.). It is necessary to collect the locking and unlocking primitives first, and determine whether the locks operated by each primitive are the same. After multiple layers of function calls, the unlocking statement of the operating system can be found. Therefore, it relies on complex inter-procedural alias analysis, which is inefficient and inaccurate.

[0071] Rust provides lifetime and move statement semantics. Each variable has a lifetime, and will be automatically released when the lifetime is exceeded. When a variable is moved to a new variable, its ownership is transferred to the new variable, and the old variable cannot be accessed.

[0072] Rust also provides an automatic unlocking mechanism. The lock function returns a variable of type LockGuard, whose lifetime is equal to its scope.

[0073] The life cycle exists in Rust's intermediate code MIR in the form of "pseudo-instructions", which are used for borrow checking by the Rust compiler. The instructions are divided into two types: StorageLive (surviving variables) and StorageDead (ending variables). Before calling the lock function, the compiler will insert a StorageLive (LockGuard) statement. When LockGuard is moved into a sub-function, it goes out of scope. After the sub-function is called, its scope ends. At this time, a StorageDead (LockGuard) statement will be inserted. Therefore, the embodiment of the present application does not need to track into the sub-function to know whether it has been unlocked, avoiding tracking between processes from locking to unlocking.

[0074] Furthermore, since LockGuard itself can only be moved but not copied, the embodiments of the present application do not need to worry about alias problems. It only needs to track the move chain to accurately obtain the movement relationship between LockGuards. There is no need to consider the alias problem of LockGuard, that is, there is no problem of two LockGuards accessing the same underlying data at the same time. This completely avoids alias analysis and degenerates alias analysis into tracking a clear move chain. Among them, the alias refers to a data location in the memory that can be accessed by multiple symbolic names of the program. If LockGuard can be copied, it will cause multiple LockGuards to access the same underlying data, which will cause an alias problem. If LockGuard can only be moved, only one LockGuard can exist at the same time, thereby avoiding the alias problem.

[0075] Finally, in the process of tracing from LockGuard to Lock, if Lock and LockGuard are located in the same function or global variables, the embodiment of the present application can directly find Lock using in-process alias analysis; otherwise, Lock comes from the function parameters, and a heuristic method is used to record the structure type of the function parameters and the field where Lock is located as the basis for alias judgment. In the blockchain program used as the experimental object, this method guarantees an accuracy rate of more than 98%. The specific explanation is as follows:

[0076] Alias ​​analysis is used to analyze alias information in a processing program, usually to find out which pointers point to the same memory address. Intra-procedural alias analysis only performs alias analysis on variables within the same function; inter-procedural alias analysis requires alias analysis across functions, so it is more complicated. By calling the locking function on the Lock object, LockGuard can be obtained. The embodiment of the present application needs to start from LockGuard and track the corresponding Lock object. This process is divided into three cases:

[0077] Case 1. Lock object and LockGuard are variables in the same function;

[0078] Case 2. The Lock object is a global variable;

[0079] Case 3: The Lock object comes from the function parameter.

[0080] For the first two cases, the embodiments of the present application utilize in-process alias analysis to directly find the corresponding Lock object from LockGuard.

[0081] For the third case, inter-procedural alias analysis can be used to find the corresponding Lock object, but through a lot of observations, it is found that the function parameter from which the Lock object comes is usually a function parameter of a structure type, and the Lock object is a field of the function parameter of the structure type. Therefore, as long as the structure type and the field sequence number are the same, the Lock objects can be considered the same. Therefore, the embodiment of the present application records the structure type and the field sequence number to represent the Lock object, without directly finding the Lock object. This greatly improves the detection accuracy and efficiency of blocking bugs related to locks in blockchain programs written in Rust.

[0082] Therefore, see Figure 1 The static detection steps of lock-related blocking bugs provided in the embodiment of the present application are as follows:

[0083] S101. Compile and obtain the intermediate intermediate code (MIR) of the Rust program.

[0084] The Rust program, i.e., the program under test, is described in the embodiments of the present application by taking the Rust program as an example, but is not limited to this.

[0085] Specifically, the API provided by the Rust compiler is called to obtain the intermediate intermediate code (MIR) of the Rust program, where the MIR consists of a series of functions.

[0086] S102, traverse all functions and their local variables in the MIR, obtain all variables of the LockGuard type, and generate a function call graph (Callgraph). The Callgraph includes the call relationship between functions in the Rust program.

[0087] Specifically, for each function in the MIR, all local variables it contains are traversed, and if the type of the local variable is LockGuard, it is recorded.

[0088] Any function in the MIR may contain a call instruction inside the function, which is used to call another function. For all functions in the MIR, the calling function and the called function are connected with directed edges to obtain the call graph of all functions in the MIR. In the subsequent step (S108), the call graph will be traversed to detect blocking bugs related to locks across functions.

[0089] It should be noted that the functions in the callgraph do not include the functions that create threads. After the callgraph is generated, the functions that create threads (such as thread::spawn) need to be deleted from the callgraph to ensure that the detection of lock-related blocking bugs occurs within a single thread.

[0090] S103. Using the Def-Use Chain provided by MIR, obtain the following four statements for each LockGuard variable: move, StorageLive, StorageDead, and a function call that returns the variable.

[0091] The Def-Use Chain is a definition-use chain, which consists of a variable definition statement and a statement that uses the variable and is directly reachable from the definition statement.

[0092] Specifically, each variable must have StorageLive and StorageDead statements, but not necessarily move and function call statements that return the variable. For each LockGuard variable, traverse its Def-Use Chain, and if the above four statements exist, record these four statements for this LockGuard variable.

[0093] S104. For each LockGuard variable that records the above four statements, use the StorageLive and StorageDead statements of the LockGuard variable to establish the life cycle scope of the LockGuard variable.

[0094] For each LockGuard variable, starting from the StorageLive statement of the LockGuard variable and ending with the StorageDead statement of the LockGuard variable, all the statements in between are the life cycle of the LockGuard variable.

[0095] S105. For each LockGuard variable that records the above four statements, a move chain of the LockGuard variable is established using the life cycle and move statement of the LockGuard variable.

[0096] The move chain of the LockGuard variable is established, that is, the lifecycles of the LockGuards with the same move statement are merged into one LockGuard, that is, the first LockGuard on the move chain represents all the LockGuards on the chain. For example, if the move statement of LockGuard A is equal to the move statement of LockGuard B, the lifecycle of LockGuard A is merged with the lifecycle of LockGuard B to form one LockGuard.

[0097] S106. Using intra-procedural alias analysis, for each LockGuard variable, using the move chain of the LockGuard variable, starting from the function call statement of the LockGuard variable, trace the Lock object that generates the LockGuard.

[0098] S107. If the tracked Lock object comes from a function or a global variable, the mapping relationship between LockGuard and the Lock object is recorded; if the tracked Lock object comes from a function parameter and the parameter is a structure, the mapping relationship between LockGuard and the structure type and field where the Lock object is located is recorded.

[0099] For example:

[0100] Case 1:

[0101]

[0102] The Lock object comes from inside the function, that is, trace lockguard to the lock object, and find that the lock object and lockguard are located in the same function foo, then record lockguard->local variable lock in the mapping table (Map).

[0103] Case 2:

[0104]

[0105] If the lock object comes from a global variable, lockguard->global variable lock is recorded in the mapping Map.

[0106] Case 3:

[0107]

[0108] The lock object comes from the function parameter b, and the parameter is the structure Bar, then lockguard->(structure type Bar, field 0) is recorded in the mapping Map.

[0109] S108. Determine at least one LockGuard pair by traversing the function call graph.

[0110] The pair refers to a container containing two elements, where the first element and the second element are fixed in position and cannot be swapped. The LockGuard pair includes two LockGuard variables.

[0111] Specifically: starting from the entry function, search the Callgraph in depth first, record the current set of surviving LockGuard variables at the beginning and end of each basic block (BasicBlock); at each function call (except for the function that returns LockGuard), pass the surviving LockGuard variable set to the called function. Wherein, every time a StorageLive statement of LockGuard is encountered, record the LockGuard pair (surviving LockGuard, the LockGuard), and add the LockGuard object to the surviving LockGuard variable set; if the StorageDead statement of LockGuard is encountered, remove the LockGuard object from the surviving LockGuard variable set. Wherein, the surviving LockGuard in the pair includes all the current surviving LockGuard variable sets. That is to say, the LockGuard pair includes at least two LockGuard variables, namely the surviving LockGuard variable that has been discovered, and the newly discovered surviving LockGuard variable.

[0112] How to determine the set of surviving LockGuard variables and how to determine the LockGuard sequence pair, for example:

[0113] At the beginning and end of all basic blocks (denoted as B) of each function (denoted as F), a set of currently alive LockGuard variables is maintained, denoted as BEFORE[F][B] and AFTER[F][B], respectively, and both are initialized to empty sets. Add all [F][B] to a queue Q and process them according to the following steps until the queue Q is empty or all BEFORE and AFTER are no longer changed:

[0114] Step 1: Pop the first basic block [F][B] from queue Q and merge BEFORE[F][B] into AFTER[F][B].

[0115] Step 2: Process the basic block [F] [B] as follows:

[0116] If [F][B] contains a StorageDead statement for a LockGuard, remove the LockGuard from AFTER [F][B];

[0117] If [F][B] contains a StorageLive statement for LockGuard, then establish a pair between each LockGuard in AFTER[F][B] and the current LockGuard (each LockGuard in AFTER[F][B], current LockGuard), and add the current LockGuard to AFTER[F][B].

[0118] Step 3: Find all basic blocks P of [F][B] that need to be processed later. The method is as follows:

[0119] If the end of B is a function call, then find all called functions F' at [F][B] according to the Callgraph, and take the first basic block [F'][B'] of function F' as P;

[0120] If the end of B is a function return, then find all locations [F”][B”] that have called F according to the Callgraph, and take the direct successor basic block of [F”][B”] as P;

[0121] If the end of B is neither a function call nor a function return, the direct successor basic block of B is taken as P. Regarding the direct successor: the end of each basic block B will point to 0, 1 or more basic blocks, and the pointed basic block is the direct successor of B.

[0122] Step 4: If AFTER[F][B] changes after step 2, add all SUCCs of B to queue Q, merge AFTER[F][B] into BEFORE[F][P], and return to step 1.

[0123] When the constraint solver is turned on, the path and condition set of each LockGuard pair will also be recorded, that is, which paths are needed to reach the second variable from the first variable of the pair, and what branch conditions are on these paths.

[0124] The depth-first search is implemented using the depth-first search algorithm (DFS), which is an algorithm for traversing or searching a tree or graph. This algorithm searches the branches of the tree as deeply as possible. When all the edges where the node v is located have been explored, the search will trace back to the starting node of the edge where the node v was found. This process continues until all nodes reachable from the source node have been found.

[0125] The basic block is a straight line code sequence, with no branching in except at the entry and no branching out except at the exit. This restricted form makes the basic block very easy to analyze.

[0126] The constraint solver (SMT Solver) is a tool for determining whether a mathematical formula has a solution.

[0127] There may be a branch statement on the path, providing multiple BasicBlocks as successors. The branch condition is included in the branch statement and is used to determine which BasicBlock is selected as the successor during actual execution.

[0128] S109. Based on the mapping relationship determined in step S107, a lock graph is obtained by mapping the LockGuard in each LockGuard pair to a corresponding Lock object, or to a structure type and field where the corresponding Lock object is located; and based on the lock graph, an information report of a blocking bug related to the lock is determined.

[0129] The lock graph reflects the processing flow relationship between locks. If there is a processing flow that starts from a lock and finally points to the lock, it means that a deadlock exists, that is, there is a blocking bug related to the lock.

[0130] Specifically: when the constraint solver is turned on, it is determined whether the conditions of the LockGuard pair are satisfied. If not, it means that the pair path is unreachable and the pair is deleted. If satisfied, it means that the pair path is reachable. After that, the LockGuard in each LockGuard pair is mapped to the corresponding Lock (or structure type and field), and the lock graph is obtained.

[0131] The condition of the LockGuard pair is the condition set of each pair in step S108. A conjunction operation is performed on the elements in all condition sets to obtain a mathematical formula, and then a constraint solver is used to determine whether the formula has a solution. If so, it means that the condition of the LockGuard pair can be satisfied, otherwise, it is not satisfied.

[0132] In step S107, the mapping relationship from LockGuard to Lock (or structure type + field) is recorded. By using this mapping relationship, the LockGuard in each sequence pair is replaced with the mapped Lock.

[0133] For example, if LockGuard1 is mapped to Lock1 and LockGuard2 is mapped to Lock2, then the pair (LockGuard1, LockGuard2) is mapped to (Lock1, Lock2), and a directed edge is created from Lock1 to Lock2. All LockGuard pairs are processed in this way, and all the directed edges obtained form the directed graph of Lock, i.e., the lock graph.

[0134] For another example, if the pair (LockGuard1, LockGuard2) is mapped to (StructType1+Field1, StructType2+Field2), a directed edge from StructType1+Field1 to StructType2+Field2 is established, where StructType represents the structure type and Field represents the field.

[0135] After obtaining the lock graph, the traditional deadlock detection algorithm based on loop detection can be used to discover lock-related blocking bugs on the lock graph, and finally determine the bug information report. The bug information report includes the source code location of the LockGuard sequence pair, the blocking trigger path and conditions, etc.

[0136] In the above step S108, a LockGuard pair is obtained. For each LockGuard variable, the StorageLive statement recorded in step S104 is used to obtain the source code position of StorageLive, that is, the source code position of the LockGuard variable. The source code position of the LockGuard pair is the source code position of the two LockGuard variables in the pair.

[0137] The path of the LockGuard sequence pair recorded in step S108 is the blocking trigger path in the Bug information report. The condition set of the LockGuard sequence pair is the condition in the Bug information report.

[0138] For example, Figure 2 As shown in the figure, for the LockGuard pair (A, B), all possible execution paths from A to B are traversed, the conditions of each branch jump on the path are collected, and the conditions are input into the constraint solver (such as z3) to determine whether the path is reachable. If the constraint solver finds that all the conditions of a path have solutions, it means that the LockGuard pair path is reachable; if there is no solution, it means that the LockGuard pair path is unreachable. For example, suppose there are two execution paths from A to B. The first execution path, such as Figure 2 The path formed by branches 1 to n corresponds to the conditions a>1, b<2, and a=3. Then a solution that satisfies all the conditions is a=3 and b=1. At this time, the constraint solver can successfully calculate the solution and output it. The second execution path, for example Figure 2 The path formed by branch 1' to branch n' corresponds to the conditions a<1, b>3, a>2. At this time, there is no solution that satisfies all the conditions. The constraint solver returns that the conditions cannot be met.

[0139] Through path traversal, all execution paths that satisfy the LockGuard sequence pair can be exhausted, so this method is complete. The constraint solver will only output a solution that satisfies the conditions. At this time, the LockGuard sequence pair path must be reachable, so this method is sound.

[0140] In order to further improve the detection efficiency or provide users with more detailed information, in practical applications, the embodiments of the present application may adopt simplified or complex configurations for the path traversal and solution modules. In a simplified configuration, the constraint solving function can be turned off. The advantages of this configuration are that it improves detection efficiency and can detect potential blocking logic errors. The disadvantage is that it may produce false positives. In a complex configuration, the constraint solver can be made to output a set of all solutions that meet the conditions. The advantage of this configuration is that it provides users with detailed blocking condition information, making it easier for users to skip all blocking conditions to fix blocking bugs. The disadvantage is that it may bring higher overhead.

[0141] For example, the source code of a lock-related blocking bug in the Ethereum blockchain program is as follows: Figure 3 shown.

[0142] Among them, the life cycle of the LockGuard in line 6 spans from line 6 to line 15. When the condition in line 7 is triggered, it enters line 9, and a new LockGuard is created in line 9. At this time, the life cycle of the LockGuard in line 6 has not ended yet. Therefore, the life cycles of the LockGuards in lines 6 and 9 are recorded in sequence as a LockGuard pair.

[0143] Since lines 6 to 9 can only pass through the branch of line 7, the path traversal for this sequence pair can only find one execution path, and this path has only one condition, namely gas_pricer == Fixed. The constraint solver finds that this condition can be satisfied (because there are no other conditions that conflict with this condition), so it is determined that this execution path is reachable.

[0144] By tracing the source of LockGuard, we found that the Locks that generated the two LockGuards all came from the first field of the Miner structure, that is, there is a loop pointing to the node itself on the lock graph, so at this point, the blocking bug related to locks has been successfully discovered in the given blockchain program. Specific examples are as follows:

[0145] For example, the following is a partial MIR of the above code obtained by the compiler (simplified here):

[0146] let_0:&Miner;

[0147] let_3:MutexGuard <u256>;

[0148] _1=_0;

[0149] _2 = &(*_1).0;

[0150] _3 = lock(&_2);

[0151] Among them, only the relevant statements of LockGuard1 in line 6 are recorded. _3 is the LockGuard type (i.e. LockGuard1), and the function that creates it is _2. Using the intra-procedural alias analysis, it is found that _2 is the alias of the first field of _1, and _1 and _0 are aliases. And _0 is a function parameter and points to the type of Miner, which is a struct. Therefore, LockGuard1 is mapped to (Miner, field 0). Another LockGuard2 in line 9 is also mapped to (Miner, field 0) in the same way. Originally, LockGuard1 pointed to LockGuard2, which was mapped to (Miner, 0) pointing to (Miner, 0), that is, there is a loop pointing to itself on the lock graph, so at this time, the blocking bug related to locks has been successfully discovered in the given blockchain program.

[0152] Finally, the Bug information is reported to the user, as shown in Table 1. The format is a list, which includes at least one record. Each record records the information of a LockGuard sequence pair. Each record includes the following contents:

[0153] The source code location list of the LockGuard sequence pair includes the following content: file name: function name: starting line number: starting column number: ending line number: ending column number;

[0154] The path list of blocking triggers includes the following content: file name: function name: line number;

[0155] The condition list includes the following contents: file name: function name: starting line number: starting column number: ending line number: ending column number: variable name: value.

[0156] This information can help developers quickly locate and fix blocking bugs during the development phase.

[0157] Table 1 A record in the lock-related blocking bug information report format:

[0158]

[0159]

[0160] Among them, miner.rs is the file name, set_minimal_gas_price is the function name, and the numbers in 6:10:6:30 are the starting line number, starting column number, ending line number, and ending column number, respectively. The same is true for 9:11:9:31. The gas_pricer in the third line is the variable name; Fixed indicates the value.

[0161] In summary, the embodiments of the present application utilize the language facility of the unique life cycle of the intermediate code MIR during Rust compilation and Rust's RAII-based automatic unlocking mechanism to completely avoid the costly and low-precision inter-procedural alias analysis in the process of generating the lock graph, thereby improving the efficiency and accuracy of static detection of Rust lock-related blocking bugs.

[0162] Traditional lock-related blocking bug detection requires tracking explicit unlocking primitives and complex inter-procedural alias analysis, which is not suitable for blockchain programs written in Rust. The embodiment of the present application utilizes Rust's life cycle and lock mechanism to implement a lock graph generation method without inter-procedural alias analysis, thereby greatly improving the accuracy and efficiency of static detection of lock-related blocking bugs in blockchain programs written in Rust. The static detection algorithm can complete the detection and report bug information for mainstream blockchain programs such as Ethereum, Solana, and Polkadot within 30 minutes, and the accuracy rate is above 98%. Other methods only take several hours in the inter-procedural alias analysis step, so it is difficult to find a tool that can detect deadlock bugs in blockchain programs written in Rust.

[0163] The blockchain blocking bug information format proposed in the embodiment of the present application is detailed, comprehensive and user-friendly, has nothing to do with the implementation language or design architecture of the blockchain, and can effectively help developers quickly locate and fix blocking bugs during the development stage based on feedback from developers.

[0164] In summary, see Figure 4 , an error detection method provided in an embodiment of the present application includes:

[0165] S401, determining a variable in the intermediate code of the program under test that is used to indicate that a thread holds a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph includes a call relationship between functions in the program under test;

[0166] The variable used to represent the thread's holding of a lock is, for example, the LockGuard variable.

[0167] S402, determining at least one variable sequence pair by traversing the function call graph, wherein the variable sequence pair includes two variables; and for each variable sequence pair, mapping each variable in the variable sequence pair to information of a corresponding lock object;

[0168] S403: Determine a lock graph of processing relationships between locks in the program under test based on information about lock objects corresponding to the variables in the variable sequence pair, and determine lock-related error information in the program under test based on the lock graph.

[0169] Optionally, determining at least one variable sequence pair by traversing the function call graph specifically includes:

[0170] The set of the currently surviving variables is determined by traversing the function call graph, and at least one of the variable sequence pairs is determined by using the set of the currently surviving variables.

[0171] Optionally, for each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including:

[0172] For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located;

[0173] Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located.

[0174] Optionally, the mapping relationship is generated in the following manner:

[0175] For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable;

[0176] If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded;

[0177] If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

[0178] Optionally, the lock object of each variable is tracked in the following manner:

[0179] For each of these variables:

[0180] Use the survival statement and end statement of the variable to establish the life cycle of the variable;

[0181] According to the life cycle of the variable, a move chain of the variable is established using the move statement of the variable; the move chain is the above-mentioned move chain;

[0182] Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

[0183] The following is an introduction to the equipment or device provided in the embodiments of the present application, in which the explanations or examples of technical features that are the same or corresponding to those described in the above method will not be repeated later.

[0184] See also Figure 5 , an error detection device provided in an embodiment of the present application includes:

[0185] The first unit 11 is used to determine the variables used to represent the thread holding the lock in the intermediate intermediate code of the program under test, and the function call graph; the variables are variables with a life cycle, and the function call graph includes the calling relationship between the functions in the program under test;

[0186] The second unit 12 is used to determine at least one variable sequence pair by traversing the function call graph, wherein the variable sequence pair includes two variables; and for each variable sequence pair, map each variable in the variable sequence pair to information of a corresponding lock object;

[0187] The third unit 13 is used to determine a lock graph of processing relationships between locks in the program under test based on information about lock objects corresponding to the variables in the variable sequence pair, and determine lock-related error information in the program under test based on the lock graph.

[0188] Optionally, determining at least one variable sequence pair by traversing the function call graph specifically includes:

[0189] The set of the currently surviving variables is determined by traversing the function call graph, and at least one of the variable sequence pairs is determined by using the set of the currently surviving variables.

[0190] Optionally, for each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including:

[0191] For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located;

[0192] Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located.

[0193] Optionally, the mapping relationship is generated in the following manner:

[0194] For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable;

[0195] If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded;

[0196] If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

[0197] Optionally, the lock object of each variable is tracked in the following manner:

[0198] For each of these variables:

[0199] Use the survival statement and end statement of the variable to establish the life cycle of the variable;

[0200] According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable;

[0201] Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

[0202] It should be noted that the division of units in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0203] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.

[0204] The embodiment of the present application provides a computing device, which may be a desktop computer, a portable computer, a smart phone, a tablet computer, a personal digital assistant (PDA), etc. The computing device may include a central processing unit (CPU), a memory, an input / output device, etc. The input device may include a keyboard, a mouse, a touch screen, etc. The output device may include a display device, such as a liquid crystal display (LCD), a cathode ray tube (CRT), etc.

[0205] The memory may include a read-only memory (ROM) and a random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In an embodiment of the present application, the memory may be used to store the program of any of the methods provided in the embodiments of the present application.

[0206] The processor calls the program instructions stored in the memory, and the processor is used to execute any of the methods provided in the embodiments of the present application according to the obtained program instructions.

[0207] For example, see Figure 6 Another error detection device provided in an embodiment of the present application includes:

[0208] Memory 620, used to store program instructions;

[0209] The processor 600 is configured to call the program instructions stored in the memory and execute according to the obtained program:

[0210] Determine a variable in the intermediate code of the program under test that is used to represent the thread's holding of a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph includes a call relationship between functions in the program under test;

[0211] By traversing the function call graph, determining at least one variable sequence pair, the variable sequence pair including two variables; and for each variable sequence pair, mapping each variable in the variable sequence pair to information of a corresponding lock object;

[0212] Based on the information of the lock objects corresponding to the variables in the variable sequence pair, a lock graph of the processing relationship between locks in the program under test is determined, and based on the lock graph, error information related to the locks in the program under test is determined.

[0213] Optionally, determining at least one variable sequence pair by traversing the function call graph specifically includes:

[0214] The set of the currently surviving variables is determined by traversing the function call graph, and at least one of the variable sequence pairs is determined by using the set of the currently surviving variables.

[0215] Optionally, for each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including:

[0216] For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located;

[0217] Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located.

[0218] Optionally, the mapping relationship is generated in the following manner:

[0219] For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable;

[0220] If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded;

[0221] If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

[0222] Optionally, the lock object of each variable is tracked in the following manner:

[0223] For each of these variables:

[0224] Use the survival statement and end statement of the variable to establish the life cycle of the variable;

[0225] According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable;

[0226] Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

[0227] The transceiver 610 (optional) is configured to receive and send data under the control of the processor 600 .

[0228] Among them, Figure 6 In the embodiment, the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by processor 600 and various circuits of memory represented by memory 620 are linked together. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface. The transceiver 610 may be a plurality of components, namely, a transmitter and a receiver, providing a unit for communicating with various other devices on a transmission medium. For different user devices, the user interface 630 may also be an interface capable of externally and internally connecting required devices, and the connected devices include but are not limited to a keypad, a display, a speaker, a microphone, a joystick, and the like.

[0229] The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 can store data used by the processor 600 when performing operations.

[0230] Optionally, the processor 600 may be a CPU (central processing unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array) or a CPLD (Complex Programmable Logic Device).

[0231] The present application embodiment also provides a computer program product or computer program, which includes a computer instruction, which is stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction so that the computer device executes any of the methods described in the above embodiments. The program product can use any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media (non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0232] The embodiment of the present application provides a computer-readable storage medium for storing computer program instructions used by the apparatus provided in the embodiment of the present application, which includes a program for executing any of the methods provided in the embodiment of the present application. The computer-readable storage medium may be a non-transitory computer-readable medium.

[0233] The computer-readable storage medium can be any available medium or data storage device that can be accessed by a computer, including but not limited to magnetic storage (such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (such as CD, DVD, BD, HVD, etc.), and semiconductor storage (such as ROM, EPROM, EEPROM, non-volatile memory (NANDFLASH), solid-state drive (SSD)), etc.

[0234] It should be understood that:

[0235] Embodiments suitable for being implemented as software code or a portion thereof and running using a processor or processing functionality are independent of the software code and may be specified using any known or future developed programming language, such as a high-level programming language such as objective-C, C, C++, C#, Java, Python, Javascript, other scripting languages, etc., or a low-level programming language such as machine language or assembler.

[0236] The implementation of the embodiments is hardware independent and may be implemented using any known or future developed hardware technology or any mixture thereof, such as a microprocessor or CPU (central processing unit), MOS (metal oxide semiconductor), CMOS (complementary MOS), BiMOS (bipolar MOS), BiCMOS (bipolar CMOS), ECL (emitter coupled logic) and / or TTL (transistor-transistor logic).

[0237] Embodiments may be implemented as separate devices, apparatuses, units, components, or functions, or in a distributed manner, for example, one or more processors or processing functions may be used or shared in a process, or one or more processing segments or processing portions may be used and shared in a process, wherein one physical processor or more than one physical processor may be used to implement one or more processing portions dedicated to a specific process as described.

[0238] The device may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such a chip or chipset.

[0239] The embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field Programmable Gate Array) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

[0240] The embodiments may also be implemented as a computer program product including a computer usable medium having computer readable program code embodied therein, the computer readable program code being adapted to perform the processes as described in the embodiments, wherein the computer usable medium may be a non-transitory medium.

[0241] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

[0242] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0243] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0244] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0245] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. An error detection method, characterized in that: The method includes: Determine a variable in the intermediate code of the program under test that is used to represent the thread's holding of a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph includes a call relationship between functions in the program under test; wherein the intermediate code is composed of a series of functions; By traversing the function call graph, determining at least one variable sequence pair, the variable sequence pair including two variables; and for each variable sequence pair, mapping each variable in the variable sequence pair to information of a corresponding lock object; Determine a lock graph of processing relationships between locks in the program under test based on information about lock objects corresponding to the variables in the variable sequence pair, and determine lock-related error information in the program under test based on the lock graph; Wherein, determining at least one variable sequence pair by traversing the function call graph specifically includes: By traversing the function call graph, the set of currently surviving variables is determined, and at least one variable sequence pair is determined using the set of currently surviving variables; wherein the variable sequence pair includes at least two variables: a discovered surviving variable and a newly discovered surviving variable; For each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including: For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located; Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located; The mapping relationship is generated in the following way: For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable; If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded; If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

2. The method according to claim 1, characterized in that The lock object of each variable is tracked in the following way: For each of these variables: Use the survival statement and end statement of the variable to establish the life cycle of the variable; According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable; Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

3. An error detection device, characterized in that: The device includes: The first unit is used to determine a variable in the intermediate code of the program under test that is used to indicate that a thread holds a lock, and a function call graph; the variable is a variable with a life cycle, and the function call graph includes a call relationship between functions in the program under test; wherein the intermediate code is composed of a series of functions; The second unit is configured to determine at least one variable sequence pair by traversing the function call graph, wherein the variable sequence pair includes two variables; and for each variable sequence pair, map each variable in the variable sequence pair to information of a corresponding lock object; A third unit is used to determine a lock graph of processing relationships between locks in the program under test based on information of lock objects corresponding to the variables in the variable sequence pair, and determine error information related to locks in the program under test based on the lock graph; Wherein, determining at least one variable sequence pair by traversing the function call graph specifically includes: By traversing the function call graph, the set of currently surviving variables is determined, and at least one variable sequence pair is determined using the set of currently surviving variables; wherein the variable sequence pair includes at least two variables: a discovered surviving variable and a newly discovered surviving variable; For each of the variable pairs, each of the variables in the variable pair is mapped to information of a corresponding lock object, specifically including: For each of the variables, generate a mapping relationship between the variable and the lock object, or a mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located; Based on the mapping relationship, each variable in each variable pair is mapped to a corresponding lock object, or a structure type where the corresponding lock object is located and a field where the lock object is located; The mapping relationship is generated in the following way: For each of the variables, starting from the function call statement of the variable, tracking the lock object generated by the variable; If the tracked lock object comes from a function or a global variable, the mapping relationship between the variable and the lock object is recorded; If the tracked lock object comes from a function parameter and the function parameter is a structure, the mapping relationship between the variable and the structure type where the lock object is located and the field where the lock object is located is recorded.

4. The device according to claim 3, characterized in that The lock object of each variable is tracked in the following way: For each of these variables: Use the survival statement and end statement of the variable to establish the life cycle of the variable; According to the life cycle of the variable, the move chain of the variable is established using the move statement of the variable; Based on the move chain of the variable, starting from the function call statement of the variable, the lock object generated by the variable is traced.

5. A computing device, characterized in that: include: A memory for storing program instructions; A processor is used to call the program instructions stored in the memory and execute the method according to claim 1 or 2 according to the obtained program.

6. A computer program product for a computer, characterized in that The invention comprises a software code part, and when the product is run on the computer, the software code part is used to perform the method according to claim 1 or 2.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable the computer to execute the method of claim 1 or 2.

Images