Method for detecting data races in node.js applications based on occurrence order rules

Abstract

The application is a Node.js application data race detection method based on a happens-before relationship rule, belongs to the technical field of computer software, and can solve the problem that it is difficult to detect data races in Node.js applications. The application proposes a happens-before relationship (HB relationship) rule for Node.js applications, divides it into three categories for different steps, and proposes an HB relationship matching rule and a resource characteristic matching rule. First, the application uses dynamic program analysis to instrument the measured application program and collect and analyze running data, extracts resource access conditions and asynchronous call HB relationships between event processing functions, and constructs an asynchronous call tree. Second, the application applies a tree reachability detection algorithm to the asynchronous call tree to detect candidate data races. Third, the application uses the HB relationship matching rule and the resource characteristic matching rule to determine whether the candidate data race is a false positive. Finally, the application outputs a data race detection report after the measured application exits.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, particularly software technology. It proposes a data race detection method for Node.js applications based on occurrence order rules. This method effectively solves the problem that existing methods struggle to detect data races in Node.js applications due to the single-threaded event loop concurrency model, thereby improving the quality and reliability of Node.js applications and reducing maintenance costs. Background Technology

[0002] Node.js has become one of the world's most popular development platforms, and its package repository, npm, is the world's largest package repository, widely used by numerous commercial companies for backend development. For backend services, concurrency is crucial. Node.js's excellent performance in high-concurrency scenarios is a major reason for its widespread popularity. Unlike the multi-threaded concurrency models used in languages ​​like C++ and Java, Node.js employs a single-threaded event loop concurrency model. Therefore, Node.js applications face significantly different data race conditions compared to multi-threaded concurrency models, making existing data race detection methods for multi-threaded concurrency models difficult to apply to Node.js applications. Data race problems in Node.js applications can lead to data errors and program crashes; therefore, detecting data races in Node.js applications is of great practical significance for ensuring their quality.

[0003] Unlike multi-threaded concurrency models, data races in Node.js applications occur between two asynchronous I / O functions called by the main thread, not between multiple threads. Due to its single-threaded event loop concurrency model, Node.js developers implement I / O operations by calling asynchronous I / O functions and passing event handlers as parameters. All event handlers are executed by only one main thread, and their execution is atomic. Calling asynchronous I / O functions does not block the main thread; I / O operations occur concurrently in the background. When an I / O operation completes, the event handler passed as a parameter is called by the main thread to process the result. The event handler passed as a parameter may contain other asynchronous I / O function calls. If two asynchronous I / O function calls target the same resource, the execution order of their respective event handlers is uncertain, and one of the I / O operations is a "write," then data races may occur between these two I / O operations. Detecting whether two event handlers have a definite execution order can typically be achieved through reachability checks on a directed acyclic graph.

[0004] For Node.js applications, existing detection methods are all based on Happens-Before (HB) graphs. An HB graph for Node.js applications is a directed acyclic graph (DAG), with event handlers as nodes and Happens-Before relationships (HB relationships) as directed edges. Existing methods use a breadth-first search (BFS) algorithm, judging data races based on whether two nodes in the HB graph are reachable. However, the HB relationship rules relied upon by existing detection methods are not precise enough, and the generated HB graphs are enormous. Their high complexity and low efficiency make them unsuitable for effective data race detection in real-world Node.js applications.

[0005] Therefore, the main objective of this invention is to further optimize the detection method based on dynamic program analysis technology by proposing more accurate HB relationship rules and resource characteristic matching rules for Node.js applications, thereby improving the accuracy and efficiency of detecting data competition in Node.js applications, making practical data competition detection for Node.js applications possible, improving the quality and reliability of Node.js applications, and reducing maintenance costs. Summary of the Invention

[0006] The main work of this invention is to study a practical method for detecting data races in Node.js applications.

[0007] At the theoretical level, compared to existing detection methods, this invention proposes more accurate HB relationship rules for the Node.js single-threaded event loop concurrency model and classifies and discusses HB relationships. This classification and discussion can simplify the detection algorithm and improve the efficiency of contention detection. Furthermore, this invention also proposes resource characteristic matching rules to further improve detection accuracy.

[0008] At the methodological level, this invention implements an algorithm for extracting asynchronous call relationships between event handling functions based on runtime data and constructing an asynchronous call tree based on the asynchronous call HB relationship; this invention implements an algorithm for extracting resource read / write operations based on runtime data and associating them with nodes in the asynchronous call tree; this invention implements a detection algorithm for inferring candidate data contention on the asynchronous call tree using a tree reachability detection algorithm based on the asynchronous call tree and resource read / write operations; this invention creates HB relationship matching rules and resource characteristic matching rules, using the matching rules to determine whether candidate data contention is a false alarm, thereby improving detection accuracy. The work and contributions of this invention are detailed below:

[0009] 1. This invention provides more precise Black-Scholes (HB) relationship rules for the Node.js single-threaded event loop concurrency model, and a classification discussion of these rules. The invention categorizes HB relationships into three types: asynchronous call HB relationships, event priority HB relationships, and event registration order HB relationships. Asynchronous call HB relationships are used for constructing the asynchronous call tree, while event priority HB relationships and event registration order HB relationships are used for false alarm detection.

[0010] 2. An algorithm for extracting asynchronous call relationships between event handling functions based on runtime data and constructing an asynchronous call tree based on these relationships. By recording the unique identifier of each event handling function, this invention can record the asynchronous call relationships between event handling functions. Based on this relationship, this invention constructs an asynchronous call tree. Simultaneously, this invention instrumentes the execution of functions to obtain the callback functions corresponding to the event handling functions, thereby mapping the event handling function identifiers to the source code.

[0011] 3. An algorithm for extracting resource access information from runtime data and associating it with corresponding nodes in the asynchronous call tree. This invention, when recording resource access, utilizes known currently executing event handling functions to establish a connection between resource accesses and the nodes of these functions in the asynchronous call tree. Therefore, reachability between resource accesses can be queried through the asynchronous call tree.

[0012] 4. Based on the asynchronous call tree and resource access information, a tree reachability detection algorithm is used to infer candidate data contention detection algorithms on the asynchronous call tree. This invention, when recording resource access, examines past access records of the resource and its associated event handling functions. Based on the asynchronous call tree, and using the tree reachability detection algorithm, it identifies potential data contention between asynchronous functions on the accessed resource.

[0013] 5. HB relationship matching rules based on event priority HB relationship and event registration order HB relationship, as well as resource characteristic matching rules based on some unique features of Node.js resources. This invention utilizes the above matching rules to determine whether candidate data competition is a false alarm. After detecting candidate data competition, this invention efficiently matches the characteristics of the candidate data competition with the matching rules, and determines whether it is a false alarm based on the matching result, thereby maintaining good detection accuracy.

[0014] Technically, this invention implements a dynamic analysis tool that performs real-time instrumentation, runtime data collection, and data race detection on the application under test. The Node.js application under test can utilize this tool to directly execute the test suite for data race detection without modification. Attached Figure Description

[0015] Figure 1Architecture diagram of a data race detection method for Node.js applications based on the order of occurrence rules Detailed Implementation

[0016] The present invention specifically includes the following steps:

[0017] 1) Use the testing tool to execute the test suite of the application under test. The testing tool will instrument the application under test and collect runtime data during the process.

[0018] 2) During the collection of runtime data, the runtime data is analyzed in real time to obtain the asynchronous call relationships between event handling functions, the correspondence between event handling functions and functions in the source code, and the event handling functions where resource access occurs. Based on the above information, an asynchronous call tree is constructed.

[0019] 3) On the asynchronous call tree, use the tree reachability algorithm to check whether there is an asynchronous call (HB) relationship between the two event handling functions that access the same resource. If not, it indicates that the order of the two accesses to the same resource may have changed, and report the resource and the two resource accesses as candidate data contention.

[0020] 4) Use HB relationship matching rules and resource characteristic matching rules to match the characteristics of candidate data competition. Determine whether it is a false alarm based on the matching results. If it is a false alarm, exclude the candidate data competition from the report.

[0021] 5) Output a report when the application under test finishes running.

[0022] Step 1) Use dynamic analysis to instrument the application under test and collect operational data. The specific operational data collected is as follows:

[0023] 1. Asynchronous initialization is called, and the unique identifiers of the calling event handler function and the called event handler function, as well as the event type, are recorded.

[0024] 2. In asynchronous calls, the unique identifier of the called event handler function is recorded.

[0025] 3. Variable declaration, variable name and the currently executing function are recorded.

[0026] 4. Variable access: The name of the accessed variable is recorded.

[0027] 5. Function literal definitions are recorded in the static scope in which they are defined.

[0028] 6. Object literal definition: A reference to the defined object is recorded.

[0029] 7. When accessing object members, the reference to the accessed object and the name of the accessed member are recorded.

[0030] 8. Function execution and exit: Function information is recorded.

[0031] 9. Synchronous function calls, the called function is recorded.

[0032] 10. Information before and after the execution of the await expression is recorded.

[0033] Step 2) Construct the asynchronous call tree using the runtime data collected in Step 1). The asynchronous call tree is constructed based on the following asynchronous HB relationship:

[0034] 1. Given events e1 and e2, if e1.handler registers e2 during execution, then e1.handler and e2.handler form an HB relationship, denoted as e1.handler→e2.handler.

[0035] 2. Given events e1, e2 and a Promise object p, if e1.handler causes p to be fulfilled, and the fulfillment of p causes e2 to be pushed into the event queue, then e1.handler → e2.handler.

[0036] This work uses the information from runtime data 1 in step 1) to confirm the asynchronous call HB relationship between event handling functions; uses the information from runtime data 2 and 8 to confirm the mapping relationship between functions and event handling functions in the source code; uses the information from runtime data 4, 6 and 7 to map resource access to event handling functions; and uses the information from runtime data 9 to record resource access called through getter / setter methods.

[0037] Based on the information from runtime data 1, 2, 4, 6, 7, 8, and 9, this work can determine the asynchronous call hierarchy (HB) relationship, mapping asynchronous call tree nodes to resource access and source code, and constructing the asynchronous call tree. To improve accuracy, this work utilizes the information from runtime data 3 and 5 for closure analysis to enhance the accuracy of the information collected in runtime data 4. Furthermore, this work leverages the information from runtime data 10 to process async / await language features, improving the mapping accuracy between resource access and event handling functions.

[0038] Step 3) On the asynchronous call tree, use the tree reachability algorithm to detect whether there is an asynchronous call (HB) relationship between the two event handling functions that access the same resource twice. The correctness of this algorithm is guaranteed by the transitivity rule of the HB relationship: given events e1, e2, and e3, if e1.handler→e2.handler and e2.handler→e3.handler, then e1.handler→e3.handler.

[0039] As can be seen from the asynchronous call HB relationship, an event handler node can only have one parent node. If two resource access operations op1∈e1.handler and op2∈e2.handler both access the same resource R, and at least one of the accesses is a "write", then for the nodes of e1.handler and e2.handler in the asynchronous call tree, this work achieves reachability determination by iteratively backtracking the parent node. According to the transitivity of the HB relationship, if e1.handler is encountered during the backtracking of the parent node of e2.handler, then there exists e1.handler→e2.handler, and the backtracking of e1.handler is similar; if the backtracking of both nodes reaches the root node, then the two nodes are unreachable, indicating that there is no asynchronous call HB relationship between the two event handlers, the execution order of op1 and op2 may be uncertain, and the value of resource R may change with the execution order. Therefore, the event handler pair reporting its location competes for RC(R, op1, op2) as candidate data.

[0040] Step 4) Use HB relationship matching rules and resource characteristic matching rules to match the characteristics of candidate data competition. Part of the HB relationship matching rules is generated based on the following event priority HB relationship rules:

[0041] 1. Given events e1 and e2, where e1 is of type TickObject and e2 is not of type TickObject, and e3.handler is the nearest parent node of e1.handler that satisfies the condition that e3 is not of type TickObject, if there is e3.handler→e2.handler or e2.handler→e3.handler, then there is e1.handler→e2.handler or e2.handler→e1.handler.

[0042] 2. Given events e1 and e2, where e1 is of type Promise and e2 is of type neither Promise nor TickObject, and e3.handler is the nearest parent node of e1.handler that satisfies the condition that e3 is not of type Promise, if there is e3.handler→e2.handler or e2.handler→e3.handler, then there is e1.handler→e2.handler or e2.handler→e1.handler.

[0043] The HB relationship matching rules generated based on the event priority HB relationship rules are as follows:

[0044] 1. Given a candidate data race RC(R, op1, op2) where op1 ∈ e1.handler and op2 ∈ e2.handler, e1 is of type TickObject, and e2 is not of type TickObject, backtrack the parent node of e1.handler until e3.handler satisfies that e3 is not of type TickObject. Check if there is an HB relationship between e1.handler and e3.handler. If it exists, then the candidate data race is considered a false alarm.

[0045] 2. Given a candidate data race RC(R, e1.handler, e2.handler), where e1 is of type Promise and e2 is not of type Promise, backtrack the parent node of e1.handler until e3.handler satisfies that e3 is not of type Promise. Check if there is a HB relationship between e1.handler and e3.handler. If it exists, then the candidate data race is considered a false alarm.

[0046] Another part of the HB relationship matching rules is generated based on the following event registration order:

[0047] 1. Given events e1, e2, ..., e n If these events are all registered sequentially using the same asynchronous function `setInterval()`, then `e1.handler`, `e2.handler`, ..., `e...` n There is a weak hexadecimal relationship between .handlers based on their registration order, denoted as e. i .handler→e j .handler, 1≤i<j≤n.

[0048] 2. Given events e1 and e2, both events are registered by two asynchronous functions setTimeout() in the same event handler function, meaning both events are of type Timeout. If e1 is registered earlier than e2, and the delay time set when e1 is registered is no greater than that of e2, then e1.handler → e2.handler.

[0049] 3. Given events e1 and e2, both events are registered in the same event handler function, and neither event is of type Timeout. If e1 is registered earlier than e2, then e1.handler → e2.handler.

[0050] The HB relationship matching rules generated based on the event registration order are as follows:

[0051] 1. Given a candidate data race RC(R, op1, op2) where op1∈e1.handler and op2∈e2.handler, e1 and e2 are both of type Timeout and are registered in the same event handler function. If e1 is registered earlier than e2 and the delay time set when e1 is registered is no greater than that of e2, then the candidate data race is determined to be a false alarm.

[0052] 2. Given a candidate data race RC(R, op1, op2) where op1∈e1.handler and op2∈e2.handler, e1 and e2 are not of type Timeout and are both registered in the same event handler function, if e1 is registered earlier than e2, then the candidate data race is determined to be a false alarm.

[0053] In addition to the HB relationship rules, this work also applies the following resource characteristic matching rules, taking into account the unique characteristics of some Node.js resources:

[0054] 1. Given a candidate data race RC(R, op1, op2), where R is of type file, op1 ∈ e1.handler, and op2 ∈ e2.handler. Since a file has two parts: permissions and content, we have (1) both op1 and op2 access the file content; and (2) either op1 or op2 accesses the file permissions, and the access type is write. If a candidate data race does not satisfy both (1) and (2), then the candidate data race is determined to be a false alarm.

[0055] 2. Given a candidate data race RC(R, op1, op2), where R is an object, op1 ∈ e1.handler, and op2 ∈ e2.handler. If the operation of op1 or op2 is to construct R, then the candidate data race is considered a false alarm.

[0056] 3. Given a candidate data race RC(R, op1, op2), where R is a variable, op1 ∈ e1.handler, op2 ∈ e2.handler. If the operation of op1 or op2 is to initialize R, then the candidate data race is considered a false alarm.

[0057] 4. Given a candidate data race RC(R, op1, op2), where R is of type ArrayBuffer, if the index range accessed in op1 and op2 does not overlap, then the candidate data race is determined to be a false alarm.

[0058] Step 5) Output Report. In this step, the tool serializes the detected data race list and outputs it as a developer-readable text file. For each data race (R, op1, op2), the report contains the following information:

[0059] 1. R: (type, name, location of function definition, location of source code definition);

[0060] 2.op1: (Access type, resource values ​​before and after access, synchronous call stack of the function being accessed, event handling function chain, and source code location being accessed).

[0061] 3.op2: Information is the same as op1.

Claims

1. A data race detection method for Node.js applications based on the order of occurrence rules, comprising the following five steps: 1) Based on the characteristics of the Node.js event loop, propose targeted HB relationship rules and discuss them by category; 2) Execute the application under test and collect runtime data. Extract the asynchronous call relationship of event handling functions based on the runtime data, and construct the asynchronous call tree based on the asynchronous call HB relationship; 3) Extract resource access information from the runtime data and associate it with the corresponding asynchronous call tree nodes; 4) Based on the asynchronous call tree and resource access status, use the tree reachability detection algorithm to infer candidate data contention on the asynchronous call tree; 5) Propose HB relationship matching rules based on event priority HB relationship rules and event registration order HB relationship rules; Based on the binary nature of Node.js file permissions and content, the lazy loading mode for objects and variables, and the underlying sharing mechanism of ArrayBuffer, resource characteristic matching rules are proposed. Using both HB relationship matching rules and resource characteristic matching rules, it is determined whether candidate data contention is a false alarm. Two HB relationship matching rules are proposed based on event priority HB relationships, two HB relationship matching rules are proposed based on event registration order HB relationships, and four resource matching rules are proposed based on the characteristics of Node.js resources. The specific rules are as follows: HB relationship matching rules: (1) Given a candidate data competition RC(R, op1, op2) and op1∈e1.handler, op2∈e2.handler, the type of e1 is TickObject, and the type of e2 is not TickObject, backtrack the parent node of e1.handler until e3.handler satisfies that the type of e3 is not TickObject, check whether there is an HB relationship between e1.handler and e3.handler. If there is, then the candidate data competition is determined to be a false alarm. (2) Given a candidate data competition RC(R, e1.handler, e2.handler), where e1 is of type Promise and e2 is not of type Promise, backtrack the parent node of e1.handler until e3.handler satisfies that e3 is not of type Promise. Check if there is an HB relationship between e1.handler and e3.handler. If there is, then the candidate data competition is determined to be a false alarm. (3) Given a candidate data competition RC(R, op1, op2) and op1∈e1.handler, op2∈e2.handler, e1 and e2 are both of type Timeout and are registered in the same event handler function. If e1 is registered earlier than e2 and the delay time set when e1 is registered is not greater than e2, then the candidate data competition is determined to be a false alarm. (4) Given a candidate data race RC(R, op1, op2) and op1∈e1.handler, op2∈e2.handler, e1 and e2 are not of type Timeout and are both registered in the same event handler function. If e1 is registered earlier than e2, then the candidate data race is determined to be a false alarm. Resource characteristic matching rules: (1) Given a candidate data competition RC(R, op1, op2), where R is a file, op1 ∈ e1.handler, op2 ∈ e2.handler, since a file has two parts: permissions and content, we have 1) both op1 and op2 access the file content; 2) op1 or op2 accesses the file permissions and the access type is write. If the candidate data competition does not satisfy 1) and 2) at the same time, then the candidate data competition is determined to be a false alarm. (2) Given a candidate data race RC(R, op1, op2), where R is of type Object, op1 ∈ e1.handler, op2 ∈ e2.handler, if the operation of op1 or op2 is to construct R, then the candidate data race is determined to be a false alarm. (3) Given a candidate data race RC(R, op1, op2), where R is a variable, op1∈e1.handler, op2∈e2.handler, if the operation of op1 or op2 is to initialize R, then the candidate data race is determined to be a false alarm. (4) Given a candidate data race RC(R, op1, op2), where R is of type ArrayBuffer, if the index range accessed in op1 and op2 does not overlap, then the candidate data race is determined to be a false alarm. (5) Based on the HB relationship matching rules and resource matching rules, the candidate data competition information is extracted and matched with the above matching rules to determine whether the candidate data competition is a false alarm.

2. The data race detection method for Node.js applications based on the order of occurrence relation rule according to claim 1, characterized in that: In step 1), eight Heap-and-Hedge (HB) relationship rules were proposed for the Node.js single-threaded event loop concurrency model. These eight rules are divided into two asynchronous call HB relationship rules, two event priority HB relationship rules, three event registration order HB relationship rules, and one transitivity rule. The specific rules are as follows: (1) Given events e1 and e2, if e1.handler registers e2 during execution, then e1.handler and e2.handler form an HB relationship, denoted as e1.handler→e2.handler; (2) Given events e1, e2 and Promise object p, if e1.handler causes p to be fulfilled, and the fulfillment of p causes e2 to be pushed into the event queue, then e1.handler→e2.handler. (3) Given events e1 and e2, e1 is of type TickObject, e2 is not of type TickObject, and e3.handler is the nearest parent node of e1.handler that satisfies that e3 is not of type TickObject. If there is e3.handler→e2.handler or e2.handler→e3.handler, then there is e1.handler→e2.handler or e2.handler→e1.handler. (4) Given events e1 and e2, e1 is of type Promise, e2 is of type neither Promise nor TickObject, and e3.handler is the nearest parent node of e1.handler that satisfies that e3 is of type neither Promise. If there is e3.handler→e2.handler or e2.handler→e3.handler, then there is e1.handler→e2.handler or e2.handler→e1.handler. (5) Given events e1, e2, ..., e n If these events are all registered sequentially using the same asynchronous function `setInterval()`, then `e1.handler`, `e2.handler`, ..., `e...` n There is a weak hexadecimal relationship between .handlers based on their registration order, denoted as e. i .handler→e j .handler, 1≤i<j≤n; (6) Given events e1 and e2, both events are registered by two asynchronous functions setTimeout() in the same event handler function, that is, both events are of type Timeout. If e1 is registered earlier than e2, and the delay time set when e1 is registered is no greater than e2, then e1.handler→e2.handler. (7) Given events e1 and e2, both events are registered in the same event handler function and neither event is of type Timeout. If e1 is registered earlier than e2, then e1.handler → e2.handler. (8) Given events e1, e2 and e3, if e1.handler→e2.handler and e2.handler→e3.handler, then e1.handler→e3.handler; Among them, rules (1) and (2) are asynchronous call HB relationship rules, rules (3) and (4) are event priority HB relationship rules, rules (5), (6) and (7) are event registration order HB relationship rules, and rule (8) is transitivity rule.

Images