Concurrent defect detection method and system based on read-write relationship

Abstract

The invention provides a concurrent defect detection method and system based on a read-write relationship, and belongs to the technical field of concurrent defect detection.The method comprises the steps that an original track is obtained, and the original track is used for triggering known concurrent defects of a detected program; adjusting a thread scheduling sequence in the original track to generate a first verification track; performing static analysis on the first verification track and the tested program to obtain a suspicious read-write relationship; according to the suspicious read-write relationship, adjusting a thread staggering sequence in the first verification track, and generating a plurality of second verification tracks; and carrying out concurrent defect testing on the tested program again by utilizing all the second verification tracks to identify whether the tested program has additional concurrent defects or not. According to the method, known defects of the concurrent program are accurately detected and potential defects are explored through a collaborative mechanism of track generation, static analysis and thread staggered sequence adjustment, so that whether extra concurrent defects exist in the complex concurrent program or not is efficiently and comprehensively detected and verified.

Description

Technical Field

[0001] The present invention relates to the technical field of concurrent defect detection, and in particular to a concurrent defect detection method and system based on read-write relationship. Background Art

[0002] With the widespread application of multi-threaded concurrent programs, while improving computing efficiency and resource utilization, it also introduces complex thread interaction issues, resulting in frequent concurrency defects (such as data competition, deadlock, etc.). These defects are not only difficult to locate, but may only appear in specific thread interleaving situations, posing a serious threat to program reliability.

[0003] Existing technologies usually perform concurrent defect detection through static analysis or dynamic scheduling. Static analysis methods can deduce potential thread dependencies in a program, but they are prone to state space explosion problems and are difficult to cover all possible thread interleaving scenarios. Dynamic scheduling methods reproduce defects by modifying the thread scheduling order, but for complex thread dependency scenarios, they cannot effectively generate comprehensive verification trajectories. In addition, during the concurrent defect repair process, the repair patch may change the dependency between threads, causing the original trajectory that triggered the defect to become invalid. Existing methods lack effective means to handle infeasible trajectories after the introduction of the patch, and cannot accurately verify the correctness of the repair or discover hidden new defects, which severely limits the accuracy and coverage of detection.

[0004] Therefore, how to efficiently and comprehensively detect and verify whether there are additional concurrency defects in complex concurrent programs has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present invention provides a concurrent defect detection method, system, electronic device and storage medium based on read-write relationship, which are used to solve the defects in the prior art and realize efficient and comprehensive detection and verification of whether there are additional concurrent defects in complex concurrent programs.

[0006] The present invention provides a concurrent defect detection method based on read-write relationship, comprising the following steps: Obtaining an original trace, where the original trace is used to trigger a known concurrent defect of the program under test; Adjusting the thread scheduling order in the original trace to generate a first verification trace; Performing static analysis on the first verification trace and the tested program to obtain suspicious read-write relationships; According to the suspicious read-write relationship, adjusting the thread interleaving order in the first verification track to generate a plurality of second verification tracks; The program under test is tested again for concurrent defects using all of the second verification traces to identify whether the program under test has additional concurrent defects.

[0007] According to a concurrent defect detection method based on read-write relationship provided by the present invention, adjusting the thread scheduling order in the original trace to generate a first verification trace specifically includes: Eliminate all threads in the original trace that are in a blocked state, and determine a first set of threads that are currently executable; Selecting a thread that schedules the earliest feasible event from the first thread set for execution, and after the thread is executed, removing all infeasible events in the thread that are earlier than the currently executed event, and refreshing the first thread set to generate a second thread set; The second thread set is used as the first thread set, and the steps of selecting a thread that schedules the earliest feasible event from the first thread set for execution are repeated. After the execution of the thread is completed, all infeasible events in the thread that are earlier than the current execution event are removed, and the first thread set is refreshed to generate the second thread set until all threads are executed. During the execution process, the complete execution traces of all threads are recorded to generate the first verification trace.

[0008] According to a concurrent defect detection method based on read-write relationship provided by the present invention, the static analysis of the first verification trace and the tested program to obtain the suspicious read-write relationship specifically includes: Determine a critical branch in the first verification trace, where the critical branch is a branch that must be satisfied for deviations to trigger a concurrent defect during execution; The suspicious read-write relationship is obtained according to a preset static dependency graph and the key branch.

[0009] According to a concurrent defect detection method based on read-write relationship provided by the present invention, the suspicious read-write relationship is obtained according to the preset static dependency graph and the key branch, specifically including: Tracking the value dependency path in a preset static dependency graph, identifying at least one critical read event in the critical branch that affects the critical branch, and a critical write event corresponding to each of the critical read events; The suspicious read-write relationship is constructed according to all the key read events and all the key write events.

[0010] According to a concurrent defect detection method based on read-write relationship provided by the present invention, adjusting the thread interleaving order in the first verification track according to the suspicious read-write relationship to generate multiple second verification tracks specifically includes: Traversing all events in the first verification track, and recording dependent events that are reachable in the first verification track; Determine the dependent events corresponding to each read-write event set in the suspicious read-write relationship, and record the execution order of each dependent event; each read-write event set includes a key read event and a corresponding key write event; According to the execution order, the read-write event set corresponding to each dependent event is scheduled, and the thread interleaving order after scheduling is recorded; wherein, in the scheduling process of each read-write event set, the key write event in the read-write event set is scheduled first, and after the key write event scheduling is completed, the key read event in the read-write event set is scheduled; After all the read and write event sets are scheduled, a plurality of the second verification traces are generated according to the thread interleaving order after the scheduling.

[0011] According to a concurrent defect detection method based on read-write relationship provided by the present invention, the method further includes: When it is identified that the program under test has an additional concurrent defect, recording the second verification trace and the additional concurrent defect; When it is identified that the program under test does not have any additional concurrent defects, it is determined that the concurrent defects corresponding to the program under test are correctly repaired.

[0012] The present invention also provides a concurrent defect detection system based on read-write relationship, comprising the following modules: An acquisition module, used for acquiring an original trace, where the original trace is used for triggering a known concurrent defect of the program under test; A first trace generation module, used for adjusting the thread scheduling order in the original trace to generate a first verification trace; An analysis module, configured to perform static analysis on the first verification trace and the program under test to obtain a suspicious read-write relationship; A second trace generation module, configured to adjust the thread interleaving order in the first verification trace according to the suspicious read-write relationship to generate a second verification trace; The verification module is used to perform a concurrent defect test on the program under test again by using the second verification track to identify whether the program under test has additional concurrent defects.

[0013] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the concurrent defect detection method based on the read-write relationship as described above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the concurrent defect detection method based on the read-write relationship as described in any one of the above is implemented.

[0015] The present invention also provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements any of the above-mentioned concurrent defect detection methods based on read-write relationships.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: By obtaining the original trace, the known concurrency defects of the tested program can be reproduced, providing basic input for verifying the patch repair effect. By adjusting the thread scheduling order in the original trace to generate the first verification trace, it can adapt to the program behavior changes after the patch is introduced while maintaining the feasibility of the execution path. By statically analyzing the first verification trace, the suspicious read-write relationship in the program can be accurately identified from the perspective of control flow and data flow. By constructing a static dependency graph and tracing the value dependency path, the key branches that may cause exceptions and their related read-write events can be located, thereby providing a clear basis for the subsequent adjustment of the thread interleaving order. By adjusting the thread interleaving order in the first verification trace according to the suspicious read-write relationship and generating the second verification trace, more potential concurrency exception scenarios can be simulated. By using the second verification trace to perform a second concurrent defect test on the tested program, the effect of the patch repair can be fully verified and possible additional defects can be identified, thereby achieving efficient and comprehensive detection and verification of whether there are additional concurrency defects in complex concurrent programs. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 This is one of the flow charts of the concurrent defect detection method based on read-write relationship provided by the present invention.

[0019] Figure 2 It is a schematic diagram of the network architecture of the airport pavement performance prediction model provided by the present invention.

[0020] Figure 3 This is the second flow chart of the concurrent defect detection method based on read-write relationship provided by the present invention.

[0021] Figure 4 This is the third flow chart of the concurrent defect detection method based on read-write relationship provided by the present invention.

[0022] Figure 5 This is the fourth flow chart of the concurrent defect detection method based on read-write relationship provided by the present invention.

[0023] Figure 6 It is a structural schematic diagram of the concurrent defect detection system based on read-write relationship provided by the present invention.

[0024] Figure 7 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] It should be noted that, in the description of the present invention, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "include one..." do not exclude the existence of other identical elements in the process, method, article or device including the elements. The orientation or positional relationship indicated by the terms "upper", "lower", etc. is based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the system or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0027] The terms "first", "second", etc. in the present invention are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" means at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0028] Combine the following Figure 1-Figure 7 The present invention describes a concurrent defect detection method, system, electronic device and storage medium based on read-write relationship.

[0029] Figure 1 This is one of the flow charts of the concurrent defect detection method based on read-write relationship provided by the present invention, such as Figure 1 As shown, including but not limited to the following steps: Step 101: Obtain the original trace, which is used to trigger the known concurrency defects of the program under test.

[0030] When implementing step 101, you first need to obtain the original trajectory τ0, which serves as the basic input for triggering the known concurrency defects of the program under test P and is used to verify the correctness of the patch repair. This is the starting point of the entire process and the basis for subsequent verification work. The original trajectory τ0 contains the specific order of thread scheduling during program execution and the key event information of each thread execution. Its notable feature is that it can reproduce the concurrency defect phenomenon of the program under test in its original state, thereby providing a clear reference for verifying the repair effect.

[0031] In order to obtain the original trajectory τ0, it is necessary to dynamically monitor and record it in the running environment of the program under test P. Specifically, by embedding the controller into the execution framework of the program under test, precise control of thread scheduling can be achieved. When the program is running, the controller executes the operation of each thread according to the established scheduling logic, and records the execution events and their order of all threads through the recorder. The recorder completely reconstructs the running trajectory of the program by capturing the life cycle events of the thread such as starting, waiting, and ending, as well as the shared variable access between threads (including read and write operations).

[0032] The core of this recording method is to fully capture the thread scheduling behavior. The controller can not only reproduce the known thread execution order, but also ensure the consistency of the trajectory τ0 in multiple experiments. This consistency is crucial to verify the patch repair effect, because if the trajectory changes randomly, it may lead to uncertainty in the test results. In addition, the recording process will mark the key points that trigger concurrency defects in program execution, including but not limited to race conditions between threads, deadlock trigger points, and data consistency issues, so as to clarify the patch repair target.

[0033] Step 102: Adjust the thread scheduling order in the original trace to generate a first verification trace.

[0034] When implementing step 102, the first verification trace τ1 is generated by adjusting the thread scheduling order in the original trace τ0. The main purpose is to adapt to the changes of the tested program P after the patch repair, while ensuring the feasibility and integrity of the verification trace. Since the introduction of the patch may cause the scheduling order or operation of some threads in the original trace τ0 to no longer be feasible, it is necessary to generate a new trace τ1 by rescheduling to cover possible execution paths, providing a reliable basis for static analysis and concurrent defect testing.

[0035] In one possible implementation, refer to Figure 2 , Figure 2 FIG. 2 is a flow chart of a concurrent defect detection method based on a read-write relationship provided by the present invention. Figure 2 As shown, step 102 specifically includes steps 201-203: Step 201: exclude all threads in a blocked state in the original trace and determine a first set of currently executable threads.

[0036] In specific implementation, the controller monitors the status of all threads in real time and determines whether the thread is in a blocked state by detecting whether the thread meets the running conditions. This judgment process is usually based on the current event of the thread and the availability of related resources. For example, if a thread is waiting for a mutex to be released or a condition variable to be satisfied, its state will be marked as blocked; if the thread can immediately execute the next event, it will be marked as executable. The controller adds all threads marked as executable to the first thread set and removes all other blocked threads.

[0037] In the process of thread screening, the controller will dynamically update the thread set based on the event dependencies and resource occupancy status of the threads. For example, the executability of a thread may depend on the resources released or the operations completed by other threads. The controller will recursively update the thread status based on these dependencies to ensure the accuracy of the thread set. At the same time, the controller will record the currently eliminated blocked threads so that their status can be re-evaluated in the subsequent scheduling process.

[0038] Through this implementation process, step 201 can effectively reduce the uncertainty and unnecessary attempts in scheduling, and improve the efficiency and success rate of overall scheduling. The effect of excluding blocked threads is mainly reflected in the following aspects: First, it ensures that subsequent scheduling is only performed in the currently executable thread, avoiding scheduling deadlock or state unreachable problems caused by blocked threads. Secondly, this step narrows the search space for thread scheduling and provides more accurate input for the heuristic scheduling algorithm, thereby accelerating the trajectory generation process. In addition, the accuracy of the first thread set is directly related to whether the generated first verification trajectory τ1 can faithfully reflect the current running logic and post-patch behavior of the program.

[0039] Step 202: Select a thread that schedules the earliest feasible event from the first thread set for execution, and after the thread is executed, remove all infeasible events in the thread that are earlier than the currently executed event, and refresh the first thread set to generate a second thread set.

[0040] In specific implementation, the controller scans all threads in the current first thread set and determines the earliest feasible event of each thread based on its event dependency and resource usage status. This process depends on the event scheduling information of the thread, such as whether the next event of the thread depends on the execution results of other threads or whether it needs to access shared resources. If the earliest feasible event of a thread meets all scheduling conditions (such as resource availability, no conflict with other threads, etc.), the event is marked as the current schedulable event. The controller selects the thread with the earliest schedulable event as the current scheduling thread and executes its corresponding event.

[0041] After a thread is selected and executed, the controller updates the event queue of the thread and removes all infeasible events that are earlier than the currently executed event. Infeasible events are usually caused by changes in scheduling logic or updates to program status. For example, some branch conditions are covered by new scheduling paths and are no longer executable. By removing these events, the event search space of the thread can be effectively reduced, avoiding meaningless scheduling attempts. In addition, the controller rechecks the status of all threads, updates the scheduling conditions of the remaining threads, and generates a new thread set as the second thread set. This update process ensures that the thread set can reflect the current real running status of the program.

[0042] In this way, step 202 can promote thread scheduling with the optimal strategy while maintaining the integrity and accuracy of the scheduling process. The effect of selecting the earliest feasible event and updating the thread set is reflected in many aspects: First, this scheduling strategy can give priority to exploring events on the critical path in the program, avoiding blocking subsequent scheduling due to the execution of low-priority events, thereby improving the efficiency of trajectory generation. Secondly, by removing infeasible events and dynamically refreshing the thread set, redundant attempts in scheduling can be significantly reduced and scheduling performance can be optimized. In addition, the generated second thread set provides an accurate thread scheduling basis for subsequent steps, ensuring the consistency of trajectory generation and the predictability of program behavior.

[0043] Step 203: Use the second thread set as the first thread set, and repeatedly select the thread that schedules the earliest feasible event from the first thread set for execution. After the thread is executed, remove all infeasible events in the thread that are earlier than the current execution event, refresh the first thread set, and generate the second thread set until all threads are executed. During the execution process, record the complete execution traces of all threads to generate a first verification trace.

[0044] In the specific implementation process, the controller will initialize a new first thread set based on the second thread set, and continue to select the thread with the earliest feasible event for execution according to the logic of step 202. After each execution is completed, the controller will update the event queue of the thread, remove the infeasible event, and recalculate the schedulability of all remaining threads to generate a new thread set. In each round of scheduling, the recorder synchronously records the thread identifier of the current scheduling, the executed events and their order, and the interaction information with other threads. These records ensure the integrity of each scheduling execution and form the basis of the final trajectory.

[0045] During the loop scheduling process, the controller will continue to check the execution status of all threads until the event queues of all threads are empty, indicating that the scheduling and execution of all threads have been completed. When the loop ends, the recorder will organize and summarize all recorded data to form a complete execution trace τ1. This trace not only includes the scheduling order between threads, but also records the event execution status of the threads and the access mode of shared resources in detail, thus fully reflecting the program behavior under the current scheduling policy.

[0046] By implementing step 203, it is possible to ensure that the generated first verification trace τ1 is complete and reproducible. This integrity is reflected in the following aspects: First, τ1 records the execution order and interaction information of all threads, and can truly reflect the current running logic of the program. Secondly, the loop scheduling method ensures that the events of all threads are fully executed, avoiding the situation where threads are missed due to improper scheduling. In addition, the generation of τ1 provides accurate and detailed basic data for the subsequent static analyzer (StaticAnalyzer), so that static analysis can more accurately identify key branches and suspicious read-write relationships.

[0047] Step 103: Perform static analysis on the first verification trace and the program under test to obtain suspicious read-write relationships.

[0048] When implementing step 103, it is necessary to perform static analysis on the first verification trace τ1 to identify suspicious read-write relationships. The core goal of this step is to locate the key branches in the program that may cause exceptions and the related read-write events by analyzing the execution behavior of the threads in the trace and their interaction information. Since the exceptions of concurrent programs usually originate from complex interactions between threads, such as race conditions, data inconsistency, etc., accurately identifying suspicious read-write relationships is crucial for subsequent adjustment of thread interleaving order and verification of program behavior.

[0049] In one possible implementation, refer to Figure 3 , Figure 3 FIG. 3 is a flow chart of a concurrent defect detection method based on a read-write relationship provided by the present invention. Figure 3 As shown, step 103 specifically includes steps 301-302: Step 301: Determine a critical branch in a first verification trace, where a critical branch is a branch that deviates from a normal control flow during execution.

[0050] In specific implementation, the static analyzer first extracts the control flow information of the program from the first verification trace τ1, including the branch jump records of the threads at runtime and the calculation results of the branch conditions. The analyzer will traverse all events involving conditional judgments in the trace and compare whether the actual execution path is consistent with the expected path. If the results of certain branch conditions do not match the logic of the normal operation of the program, or the results of the conditions cause the program to enter an abnormal state, such as deadlock, data competition, etc., the branch will be marked as a critical branch.

[0051] In order to more accurately identify critical branches, the static analyzer will combine the dependencies of each branch condition in the trace to analyze the key variables or operations that lead to the conditional results. For example, a branch condition may depend on the value of a global variable. The static analyzer will trace the source of the variable and locate the thread or event that affects its value. This process relies on the Static Dependency Graph (SDG), which has been constructed in step 103 and is used to describe the control dependency and data dependency between events in the program.

[0052] When locating critical branches, the analyzer also evaluates the abnormality and importance of the branch. For example, if the execution of a branch directly leads to an abnormal exit or inconsistent state of the program, the branch is marked as a critical branch first. At the same time, the analyzer records the threads, events, and conditional variables related to the branch to provide detailed context information for subsequent analysis.

[0053] Through the above process, the static analyzer can accurately determine all critical branches in the trace and generate a list of critical branches, including detailed information such as the specific location of each branch, conditional variables and its dependent events.

[0054] Step 302: Obtain suspicious read-write relationships according to a preset static dependency graph and key branches.

[0055] When implementing step 302, it is necessary to construct suspicious read-write relationships based on the preset static dependency graph and key branches. The core goal of this step is to use the static dependency structure of the program and the key branch information extracted from the trajectory to accurately locate the key read-write events and their dependencies that cause abnormal behavior, and provide a basis for subsequent adjustment of thread interleaving order and verification of program behavior. Exceptions in concurrent programs usually arise from complex data competition or control flow interference between threads, so in-depth analysis of read-write relationships is a key link in exposing potential problems and optimizing program design.

[0056] In one possible implementation, refer to Figure 4 , Figure 4 FIG. 4 is a flow chart of a concurrent defect detection method based on a read-write relationship provided by the present invention. Figure 4 As shown, step 302 specifically includes steps 401-402: Step 401: Trace the value dependency path in a preset static dependency graph, identify at least one critical read event in a critical branch that affects the critical branch, and a critical write event corresponding to each critical read event.

[0057] In the specific implementation, the static analyzer first extracts the condition information of the key branch from the first verification trace τ1 and the static dependency graph (SDG). The condition of the key branch is usually based on the value or calculation result of the variable. For example, a branch condition depends on the value of a global variable or the return value of a function. The static analyzer checks the variables involved in the branch condition and determines that it is the target variable that needs further analysis.

[0058] Next, the analyzer uses the value dependency path recorded in the static dependency graph to reverse trace the target variable. The value dependency path describes the source of the variable value in the program and how it propagates. For example, the value of a variable may come directly from the write operation of other threads, or it may be the result of indirect influence through function calls or intermediate variables. The analyzer traces back along the dependency path and identifies all write events that can affect the current value of the target variable. These events are marked as critical write events. At the same time, the analyzer marks the event of reading the target variable value as a critical read event.

[0059] During the tracing process, in order to improve efficiency and focus on the root cause of the exception, the analyzer will prioritize tracing the nearest dependent path directly related to the critical branch condition. For example, if the judgment of a branch condition depends on the global variable x, and the value of x is directly written by a thread in the current trace, the analyzer will prioritize marking the write event as a critical write event and ignore more distant potentially influential events. This distance-based analysis strategy can effectively narrow the scope of analysis and avoid excessive expansion of the state space due to interference from irrelevant events.

[0060] Finally, the static analyzer outputs a set of key read and write events directly related to the key branches. Each pair of events explicitly contains the name of the variable, the thread and location of the read and write operations, and the value dependency path information between them, providing complete data support for the subsequent construction of suspicious read and write relationships.

[0061] Step 402: Construct suspicious read-write relationships based on all key read events and all key write events.

[0062] In specific implementation, the static analyzer first receives the critical read events and critical write events identified in step 401. These events are obtained by tracing the value dependency path in the static dependency graph and are directly associated with the conditional results of the critical branch. The analyzer pairs each pair of critical read and write events to determine their specific dependencies. For a critical read event, the analyzer locates all critical write events that can affect its value, and records the thread sources, execution order, and variable operation methods of these events.

[0063] When constructing suspicious read-write relationships, the analyzer pays special attention to the following two types of dependencies: Direct dependency: The result of a critical write event is directly used in a critical read event, such as the value of a global variable being read by another thread after being written.

[0064] Indirect dependency: The value of a critical read event depends on an intermediate variable or function call, and the source of the value can be traced back to one or more critical write events. The analyzer records these indirect relationships through the value dependency path across threads in the static dependency graph.

[0065] To clearly express these dependencies, the analyzer generates description information for each key read and write event pair, including the following: Variable name: The identifier of the global variable or shared resource being read or written.

[0066] Thread ID: The thread identifier that executes the read and write events.

[0067] Execution order: The time order of key write events and key read events in the trace, based on the causal relationship of the vector clock.

[0068] Dependency path: The value dependency path from the write event to the read event, including detailed information of intermediate variables or intermediate events.

[0069] During the build process, the analyzer also detects possible race conditions, such as multiple threads interleaving read and write operations on the same variable. Such races are often the main cause of concurrency anomalies and need to be marked and recorded. In addition, to avoid redundant data, the analyzer merges duplicate dependencies and only retains representative key event pairs.

[0070] After completing the analysis, the static analyzer outputs a set of suspicious read-write relationships. These relationships not only reflect the interaction logic between threads in the program, but also reveal the key events and their dependent paths that may cause exceptions, providing a clear basis for subsequent adjustment of the thread interleaving order.

[0071] Step 104: According to the suspicious read-write relationship, the thread interleaving order in the first verification trace is adjusted to generate a plurality of second verification traces.

[0072] When implementing step 104, it is necessary to adjust the thread interleaving order in the first verification trace according to the suspicious read-write relationship generated in step 103 to generate multiple second verification traces τ2. The core goal of this step is to explore new execution paths that may cause program concurrency exceptions by changing the thread scheduling logic, thereby comprehensively verifying the concurrent behavior of the program under test and evaluating the repair effect of the patch in different concurrency scenarios. Since the concurrency defects of the program are usually caused by a specific thread interleaving order, adjusting the thread interleaving order is an important method to expose potential problems and verify the correctness of the repair.

[0073] In one possible implementation, refer to Figure 5 , Figure 5 FIG. 5 is a flowchart of a concurrent defect detection method based on a read-write relationship provided by the present invention. Figure 5 As shown, step 104 specifically includes steps 501-504: Step 501: traverse all events in the first verification trace and record the reachable dependent events in the first verification trace.

[0074] In specific implementation, the trace generator (Trace Generator) uses the first verification trace τ1 and the suspicious read-write relationship generated in step 103 as the basis, and uses the vector clock mechanism to perform dependency analysis on each event in the trace. The trace generator first traverses all events in τ1 and marks the key read events and write events involved according to the suspicious read-write relationship. For each marked event, the trace generator traces its dependency path and identifies the dependent events related to it. Dependent events generally include the following categories: write events that update shared variable values, read events that read shared variable values, and events that have a direct impact on branch conditions.

[0075] When recording dependent events, the trace generator uses a vector clock algorithm to maintain the causal relationship between events, ensuring that the interaction logic between threads is accurately reflected. The vector clock records the order of events and the dependencies across threads by assigning an independent timestamp to each thread. For example, when a write event affects a read event in another thread, the vector clock records the causal relationship between the two to ensure that this dependency order is maintained in subsequent trace adjustments. For each event, the trace generator stores its dependent event set as metadata for the event for reference when adjusting the thread interleaving order.

[0076] Through this traversal and recording, the trace generator can not only clarify the dependencies of each event, but also clearly present the interaction logic between threads and the access mode of shared resources. This information is crucial for accurately adjusting the thread interleaving order and generating reasonable traces in subsequent steps.

[0077] Step 502: Determine the dependent events corresponding to each read-write event set in the suspicious read-write relationship, and record the execution order of each dependent event; each read-write event set includes a key read event and a corresponding key write event.

[0078] In specific implementation, the trace generator first maps suspicious read-write relationships to actual events in the trace based on the dependency events recorded in step 501. For each suspicious read-write relationship, the trace generator locates the key read event and the key write event from the first verification trace τ1, confirms their specific location in the trace and thread ownership. At the same time, the trace generator tracks the dependency paths of these events based on the causal relationship recorded by the vector clock, and marks all dependency events directly associated with them.

[0079] After determining the dependent events, the trace generator arranges them according to the execution order of the events. The execution order is determined by the timestamps in the trace and the causal relationship between threads, ensuring that the order of dependent events is consistent with the actual execution logic of the program. For example, if a write event is earlier in time than its corresponding read event, the trace generator will prioritize the write event and associate it with the read event. In addition, the trace generator also handles cross-thread dependencies and ensures that the event order of cross-thread dependencies is accurately captured through vector clock comparison operations.

[0080] In the process of recording the execution order, the trace generator generates a complete set of dependent event lists for each set of read and write events. Each list contains detailed information about the dependent events, including the thread ID of the event, the execution time, the operation type (read or write), and the name of the affected shared variable. This information is not only used to describe the dependency relationship between events, but also provides a basis for the subsequent adjustment of the thread interleaving order to ensure that the adjusted trace can maintain the correctness of the program logic.

[0081] Step 503: Schedule the read-write event set corresponding to each dependent event according to the execution order, and record the thread interleaving order after scheduling; wherein, in the scheduling process of each read-write event set, the key write event in the read-write event set is scheduled first, and after the scheduling of the key write event is completed, the key read event in the read-write event set is scheduled.

[0082] In specific implementation, the trace generator (Trace Generator) schedules and adjusts each read and write event set one by one based on the dependent events and their execution order recorded in step 502. The trace generator first selects a target read and write event set, confirms its corresponding key read events and key write events, and the dependent events related to them. Then, according to the causal relationship marked by the vector clock, the dependent events are sorted to ensure that they have been executed before the read and write events are scheduled, thereby maintaining the logical consistency of the events.

[0083] During the scheduling process, the trajectory generator prioritizes the critical write event, because the execution of the write event will directly affect the value of the critical read event, which may change the running logic of the program. After the scheduling is completed, the trajectory generator will mark the write event as completed and update the status of its subsequent dependent events to confirm whether the critical read event meets the execution conditions. When all the dependent conditions of the critical read event are met, the trajectory generator schedules the critical read event and records its results in the trajectory.

[0084] To ensure the rationality of scheduling adjustments, the trajectory generator will update the thread status and schedulable event set in real time after each scheduling is completed. For example, when a critical write event is completed, the read events in other threads that depend on the write event will be marked as schedulable, and thus will be given priority in the next round of scheduling. Through this dynamic update mechanism, the trajectory generator gradually completes the scheduling adjustments of all read and write event sets, and finally generates a complete scheduling path.

[0085] This adjustment process is designed to explore scenarios that may cause concurrency defects in the program, so the trajectory generator monitors abnormal behavior in real time during the scheduling process. For example, if a scheduling adjustment causes inconsistent values ​​of shared resources or triggers a deadlock, the trajectory generator will record the abnormal information and mark the current scheduling path as a potential defect scenario. This information will be passed to subsequent testing stages to verify the effectiveness of the patch repair.

[0086] Step 504: after all read and write event sets are scheduled, multiple second verification traces are generated according to the thread interleaving order after scheduling.

[0087] In specific implementation, after the trace generator completes the scheduling adjustment of all read and write event sets, it integrates each event in the order of execution. This integration process needs to maintain the integrity of the program logic to ensure that the causal relationship between events and the dependency path between threads are not destroyed. The trace generator first extracts the event sequence of each thread from the adjusted scheduling information, and globally sorts the events between threads based on the causal relationship of the vector clock. This sorting method can accurately capture the interaction logic across threads, for example, the read event affected by a write event always occurs after it.

[0088] When generating a trace, the trace generator processes each event one by one to ensure that its dependent events are included in the prologue of the trace. For cross-thread dependencies, the trace generator ensures that the order of events conforms to the causal chain between threads by comparing the timestamps and vector clock values. For example, if a read event depends on a write event of another thread, the write event must be recorded before the read event in the trace. In this way, the trace generator can maintain the interaction logic between threads while avoiding logical conflicts caused by scheduling adjustments.

[0089] After completing the global integration, the trajectory generator generates multiple second verification trajectories τ2 and compares them with the first verification trajectory τ1 to record the newly added thread interleaving scenarios and potential exception information. The generated τ2 not only covers the unexplored concurrent paths in the original trajectory, but also simulates more concurrent situations that may cause exceptions by adjusting the scheduling order, providing more comprehensive data support for verifying the patch repair effect.

[0090] Step 105: Perform concurrent defect testing on the program under test again using all the second verification traces to identify whether the program under test has additional concurrent defects.

[0091] When implementing step 105, it is necessary to use the entire second verification trace τ2 to perform concurrency defect testing on the program under test P to identify whether the program has additional concurrency defects. The core goal of this step is to verify its behavior after the patch repair by running the program in a new thread interleaving scenario and explore potential exceptions or boundary conditions. The introduction of the patch may fix a known defect, but its impact on other thread interaction scenarios needs to be verified. Therefore, testing through τ2 can comprehensively evaluate the effectiveness and robustness of the patch.

[0092] In the specific implementation, the controller and the recorder work together to reproduce the execution order of τ2. The controller accurately controls the order of thread execution according to the scheduling information of τ2, ensuring that the execution of each event strictly follows the dependency and causal order in the trajectory. The recorder monitors the state changes during the program running in real time, capturing the execution information of threads, the access to shared resources, and potential exception information.

[0093] During the test, the controller will gradually schedule each event in τ2 and dynamically detect the running status of the program. For example, for events that read and write shared variables, the recorder will check whether there is data competition or condition variables are not satisfied. For branch judgment or lock mechanisms, the recorder will analyze whether the branch condition is triggered correctly or whether the lock causes the thread to deadlock. If abnormal behavior is detected during execution, such as deadlock, crash, or data inconsistency, the recorder will immediately record the exception information, including the trigger point of the exception, the threads and shared resources involved, and the related dependency events.

[0094] In a possible implementation, after step 105, the method further includes the following steps: When additional concurrent defects are identified in the program under test, a second verification trace and the additional concurrent defects are recorded; When it is identified that no additional concurrency defects exist in the program under test, it is determined that the concurrency defects corresponding to the program under test are correctly repaired.

[0095] In specific implementation, when an exception occurs during the test, such as thread deadlock, data inconsistency, or system crash, the recorder will immediately capture the exception event and associate it with the scheduling information in τ2 to locate the thread interaction and key events that triggered the exception. The recorder will also analyze the set of read and write events related to the exception, extract the shared variables, thread identifiers, and time sequence affected by the exception, and form a complete exception description.

[0096] At the same time, the controller will backtrack and analyze the triggering path of the abnormal behavior, and use the vector clock to confirm the causal relationship between the abnormal event and its dependent events, ensuring that the recorded abnormal information can accurately reflect the interaction logic between threads. All information related to the exception, including the exception type, triggering conditions, the set of events involved, and the thread scheduling order, will be stored as an exception report and recorded together with τ2. These reports provide clear goals for subsequent patch optimization, making it easier for developers to analyze the causes of new defects and take repair measures.

[0097] When the concurrency defect test of the second verification trace τ2 does not find additional defects, it is confirmed that all thread interaction behaviors are in line with the expected logic of the program and no known or additional concurrency defects are triggered. It is confirmed that the concurrency defects corresponding to the tested program have been correctly fixed, and the test results are summarized into a verification report, which includes an effectiveness analysis of the patch repair, a description of the concurrency scenarios covered by the trace, and a performance evaluation of the program under multiple interaction logics.

[0098] Reference Figure 6 , Figure 6 : is a structural diagram of a concurrent defect detection system based on a read-write relationship provided by the present invention, the system comprising: The acquisition module is used to obtain the original trace, which is used to trigger the known concurrency defects of the program under test; A first trace generation module, used for adjusting the thread scheduling order in the original trace to generate a first verification trace; An analysis module, used for performing static analysis on the first verification trace and the program under test to obtain suspicious read-write relationships; A second trace generation module, configured to adjust the thread interleaving order in the first verification trace according to the suspicious read-write relationship to generate a second verification trace; The verification module is used to perform a concurrent defect test on the program under test again using the second verification track to identify whether the program under test has additional concurrent defects.

[0099] In a possible implementation, the first trajectory generating module is further configured to: Eliminate all threads in a blocked state in the original trace, and determine a first set of currently executable threads; Selecting a thread that schedules the earliest feasible event from the first thread set for execution, and after the thread is executed, removing all infeasible events in the thread that are earlier than the currently executed event, and refreshing the first thread set to generate a second thread set; The second thread set is used as the first thread set, and the steps of selecting a thread that schedules the earliest feasible event from the first thread set for execution are repeated. After the execution of the thread is completed, all infeasible events in the thread that are earlier than the current execution event are removed, and the first thread set is refreshed to generate the second thread set until all threads are executed. During the execution process, the complete execution traces of all threads are recorded to generate a first verification trace.

[0100] In a possible implementation, the analysis module is further used for: Determine a critical branch in the first verification trace, where the critical branch is a branch that deviates from a normal control flow during execution; According to the preset static dependency graph and key branches, the suspicious read-write relationship is obtained.

[0101] In a possible implementation, the analysis module is further used for: Tracking the value dependency path in a preset static dependency graph, identifying at least one critical read event in a critical branch that affects the critical branch, and a critical write event corresponding to each critical read event; Based on all key read events and all key write events, a suspicious read-write relationship is constructed.

[0102] In a possible implementation manner, the second trajectory generating module is further configured to: Traverse all events in the first verification trace and record the dependent events that are reachable in the first verification trace; Determine the dependent events corresponding to each read-write event set in the suspicious read-write relationship, and record the execution order of each dependent event; each read-write event set includes a key read event and a corresponding key write event; According to the execution order, the read-write event set corresponding to each dependent event is scheduled, and the thread interleaving order after scheduling is recorded; wherein, in the scheduling process of each read-write event set, the key write event in the read-write event set is scheduled first, and the key read event in the read-write event set is scheduled after the key write event scheduling is completed; After all read and write event sets are scheduled, a second verification trace is generated according to the thread interleaving order after scheduling.

[0103] In a possible implementation, the verification module is further used to: When additional concurrent defects are identified in the program under test, a second verification trace and the additional concurrent defects are recorded; When it is identified that no additional concurrency defects exist in the program under test, it is determined that the concurrency defects corresponding to the program under test are correctly repaired.

[0104] It should be noted that the concurrent defect detection system based on read-write relationship provided by the present invention can execute the concurrent defect detection method based on read-write relationship of any of the above embodiments during specific operation, which will not be elaborated in this embodiment.

[0105] Figure 7 is a schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 7 As shown, the electronic device may include: a processor 710 (processor), a communication interface 720 (CommunicationsInterface), a memory 730 (memory) and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other through the communication bus 740. The processor 710 may call the logic instructions in the memory 730 to execute a concurrent defect detection method based on a read-write relationship, the method comprising: obtaining an original trace, the original trace is used to trigger a known concurrent defect of the program under test; adjusting the thread scheduling order in the original trace to generate a first verification trace; performing static analysis on the first verification trace and the program under test to obtain a suspicious read-write relationship; adjusting the thread interleaving order in the first verification trace according to the suspicious read-write relationship to generate a second verification trace; and performing a concurrent defect test on the program under test again using the second verification trace to identify whether there are additional concurrent defects in the program under test.

[0106] In addition, the logic instructions in the above-mentioned memory 730 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the 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.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0107] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the concurrency defect detection method based on read-write relationship provided by the above-mentioned embodiments, and the method includes: obtaining an original trajectory, and the original trajectory is used to trigger a known concurrency defect of the program under test; adjusting the thread scheduling order in the original trajectory to generate a first verification trajectory; performing static analysis on the first verification trajectory and the program under test to obtain a suspicious read-write relationship; adjusting the thread interleaving order in the first verification trajectory according to the suspicious read-write relationship to generate a second verification trajectory; and performing another concurrency defect test on the program under test using the second verification trajectory to identify whether there are additional concurrency defects in the program under test.

[0108] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by the processor 710, is implemented to execute the concurrency defect detection method based on read-write relationship provided in the above-mentioned embodiments, the method comprising: obtaining an original trajectory, the original trajectory being used to trigger a known concurrency defect of the program under test; adjusting the thread scheduling order in the original trajectory to generate a first verification trajectory; performing static analysis on the first verification trajectory and the program under test to obtain a suspicious read-write relationship; adjusting the thread interleaving order in the first verification trajectory according to the suspicious read-write relationship to generate a second verification trajectory; and performing another concurrency defect test on the program under test using the second verification trajectory to identify whether there are additional concurrency defects in the program under test.

[0109] The system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0110] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0111] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A concurrent defect detection method based on read-write relationship, characterized in that: include: Obtaining an original trace, where the original trace is used to trigger a known concurrent defect of the program under test; Adjusting the thread scheduling order in the original trace to generate a first verification trace; Performing static analysis on the first verification trace and the tested program to obtain suspicious read-write relationships; According to the suspicious read-write relationship, adjusting the thread interleaving order in the first verification track to generate a plurality of second verification tracks; The program under test is tested again for concurrent defects using all of the second verification traces to identify whether the program under test has additional concurrent defects.

2. The concurrent defect detection method based on read-write relationship according to claim 1, characterized in that: The step of adjusting the thread scheduling order in the original trace to generate a first verification trace specifically includes: Eliminate all threads in the original trace that are in a blocked state, and determine a first set of threads that are currently executable; Selecting a thread that schedules the earliest feasible event from the first thread set for execution, and after the thread is executed, removing all infeasible events in the thread that are earlier than the currently executed event, and refreshing the first thread set to generate a second thread set; The second thread set is used as the first thread set, and the steps of selecting a thread that schedules the earliest feasible event from the first thread set for execution are repeated. After the execution of the thread is completed, all infeasible events in the thread that are earlier than the current execution event are removed, and the first thread set is refreshed to generate the second thread set until all threads are executed. During the execution process, the complete execution traces of all threads are recorded to generate the first verification trace.

3. The concurrent defect detection method based on read-write relationship according to claim 1, characterized in that: The performing static analysis on the first verification trace and the tested program to obtain a suspicious read-write relationship specifically includes: Determine a critical branch in the first verification trace, where the critical branch is a branch that must be satisfied for deviations to trigger a concurrent defect during execution; The suspicious read-write relationship is obtained according to a preset static dependency graph and the key branch.

4. The concurrent defect detection method based on read-write relationship according to claim 3, characterized in that: The obtaining the suspicious read-write relationship according to the preset static dependency graph and the key branch specifically includes: Tracking the value dependency path in a preset static dependency graph, identifying at least one critical read event in the critical branch that affects the critical branch, and a critical write event corresponding to each of the critical read events; The suspicious read-write relationship is constructed according to all the key read events and all the key write events.

5. The concurrent defect detection method based on read-write relationship according to claim 1, characterized in that: The step of adjusting the thread interleaving order in the first verification trace according to the suspicious read-write relationship to generate a plurality of second verification traces specifically includes: Traversing all events in the first verification track, and recording dependent events that are reachable in the first verification track; Determine the dependent events corresponding to each read-write event set in the suspicious read-write relationship, and record the execution order of each dependent event; each read-write event set includes a key read event and a corresponding key write event; According to the execution order, the read-write event set corresponding to each dependent event is scheduled, and the thread interleaving order after scheduling is recorded; wherein, in the scheduling process of each read-write event set, the key write event in the read-write event set is scheduled first, and after the key write event scheduling is completed, the key read event in the read-write event set is scheduled; After all the read and write event sets are scheduled, a plurality of the second verification traces are generated according to the thread interleaving order after the scheduling.

6. The concurrent defect detection method based on read-write relationship according to claim 1, characterized in that: The method further comprises: When it is identified that the program under test has an additional concurrent defect, recording the second verification trace and the additional concurrent defect; When it is identified that the program under test does not have any additional concurrent defects, it is determined that the concurrent defects corresponding to the program under test are correctly repaired.

7. A concurrent defect detection system based on read-write relationship, characterized in that: include: An acquisition module, used for acquiring an original trace, where the original trace is used for triggering a known concurrent defect of the program under test; A first trace generation module, used for adjusting the thread scheduling order in the original trace to generate a first verification trace; An analysis module, configured to perform static analysis on the first verification trace and the program under test to obtain a suspicious read-write relationship; A second trace generation module, configured to adjust the thread interleaving order in the first verification trace according to the suspicious read-write relationship, and generate a plurality of second verification traces; The verification module is used to perform a concurrent defect test on the program under test again by using all the second verification traces to identify whether the program under test has additional concurrent defects.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the concurrent defect detection method based on the read-write relationship as described in any one of claims 1-6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the concurrent defect detection method based on read-write relationship as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the concurrent defect detection method based on read-write relationship as described in any one of claims 1 to 6 is implemented.

Images