A concurrent defect detection method and system based on read-write relationship

Abstract

The application provides a concurrent defect detection method and system based on read-write relationship, and belongs to the technical field of concurrent defect detection, and comprises the following steps: acquiring an original track, the original track being used for triggering a known concurrent defect of a program to be tested; 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 program to be tested to obtain a suspicious read-write relationship; adjusting a thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate a plurality of second verification tracks; and performing re-concurrent defect testing on the program to be tested by using all the second verification tracks to identify whether the program to be tested has an additional concurrent defect. Through the cooperative mechanism of track generation, static analysis and thread interleaving sequence adjustment, the known defects of the concurrent program can be accurately detected and the potential defects can be explored, so that whether the additional concurrent defect exists in the complex concurrent program can be efficiently and comprehensively detected and verified.

Description

TECHNICAL FIELD

[0001] The present application 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

[0002] With the wide application of multi-thread concurrent programs, they not only improve the computing efficiency and resource utilization, but also introduce complex thread interaction problems, resulting in frequent concurrent defects (such as data race, deadlock, etc.). These defects are not only difficult to locate, but also may only appear under specific thread interleaving conditions, posing a serious threat to the reliability of the program.

[0003] The prior art usually detects concurrent defects through static analysis or dynamic scheduling. The static analysis method can deduce the potential thread dependency relationship in the program, but it is easy to face the state space explosion problem and difficult to cover all possible thread interleaving scenarios. The dynamic scheduling method reproduces defects by modifying the thread scheduling order, but for complex thread dependency scenarios, it cannot effectively generate comprehensive verification trajectories. In addition, in the concurrent defect repair process, the repair patch may change the dependency relationship between threads, resulting in the invalidation of the original defect-triggering trajectory. The existing method lacks effective means to handle infeasible trajectories introduced after the patch, and cannot accurately verify the correctness of the repair or dig out hidden new defects, which seriously limits the accuracy and coverage of the detection.

[0004] Therefore, how to efficiently and comprehensively detect and verify whether there are additional concurrent defects in complex concurrent programs has become a technical problem to be solved. SUMMARY

[0005] The present application provides a concurrent defect detection method and system based on read-write relationship, an electronic device and a storage medium, to solve the defects in the prior art and efficiently and comprehensively detect and verify whether there are additional concurrent defects in complex concurrent programs.

[0006] The present application provides a concurrent defect detection method based on read-write relationship, comprising the following steps:

[0007] Obtain an original trajectory, which is used to trigger known concurrent defects of a program under test;

[0008] Adjust the thread scheduling order in the original trajectory to generate a first verification trajectory;

[0009] Perform static analysis on the first verification trajectory and the program under test to obtain suspicious read-write relationships;

[0010] According to the suspicious read-write relationships, adjust the thread interleaving order in the first verification trajectory to generate a plurality of second verification trajectories;

[0011] performing re-concurrent defect testing on the program under test using all of the second verification traces to identify whether the program under test has additional concurrent defects.

[0012] According to the concurrent defect detection method based on read-write relationship provided by the application, the thread scheduling sequence in the original trace is adjusted to generate a first verification trace, and the method specifically comprises:

[0013] all threads in a blocking state in the original trace are excluded to determine a first thread set that can be currently executed;

[0014] a thread that schedules the earliest feasible event is selected from the first thread set for execution, and after the execution of the thread is completed, all infeasible events earlier than the currently executed event in the thread are removed, the first thread set is refreshed, a second thread set is generated, and the second thread set is taken as the first thread set.

[0015] the step of selecting a thread that schedules the earliest feasible event from the first thread set for execution, and after the execution of the thread is completed, removing all infeasible events earlier than the currently executed event in the thread, and refreshing the first thread set to generate a second thread set is repeatedly performed until all threads are executed, and the complete execution trace of all threads is recorded during the execution process to generate the first verification trace.

[0016] According to the concurrent defect detection method based on read-write relationship provided by the application, the first verification trace and the program under test are statically analyzed to obtain a suspicious read-write relationship, and the method specifically comprises:

[0017] a critical branch in the first verification trace is determined, and the critical branch is a branch that must be met during the execution process to deviate from triggering a concurrent defect;

[0018] the suspicious read-write relationship is obtained according to a preset static dependency graph and the critical branch.

[0019] According to the concurrent defect detection method based on read-write relationship provided by the application, the suspicious read-write relationship is obtained according to a preset static dependency graph and the critical branch, and the method specifically comprises:

[0020] a value dependency relationship path is tracked in the preset static dependency graph, at least one key read event that has an impact on the critical branch in the critical branch and a key write event corresponding to each key read event are identified;

[0021] the suspicious read-write relationship is constructed according to all of the key read events and all of the key write events.

[0022] According to the application, a concurrent defect detection method based on read-write relationship is provided, which comprises the following steps:

[0023] Traverse all events in the first verification track and record the reachable dependent events in the first verification track;

[0024] 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 comprises a key read event and a corresponding key write event;

[0025] According to the execution order, schedule each read-write event set corresponding to each dependent event and record the thread interleaving order after scheduling; during the scheduling of each read-write event set, the key write event in the read-write event set is scheduled preferentially and the key read event in the read-write event set is scheduled after the scheduling of the key write event is completed;

[0026] After the scheduling of all read-write event sets is completed, a plurality of second verification tracks are generated according to the thread interleaving order after scheduling.

[0027] According to the application, a concurrent defect detection method based on read-write relationship is provided, which further comprises the following steps:

[0028] When it is identified that the tested program has additional concurrent defects, record the second verification track and the additional concurrent defects;

[0029] When it is identified that the tested program has no additional concurrent defects, it is determined that the concurrent defects corresponding to the tested program are correctly repaired.

[0030] The application further provides a concurrent defect detection system based on read-write relationship, which comprises the following modules:

[0031] An acquisition module is configured to acquire an original track, wherein the original track is used to trigger the known concurrent defects of the tested program;

[0032] A first track generation module is configured to adjust the thread scheduling order in the original track and generate a first verification track;

[0033] An analysis module is configured to perform static analysis on the first verification track and the tested program and obtain suspicious read-write relationship;

[0034] A second track generation module is configured to adjust the thread interleaving order in the first verification track according to the suspicious read-write relationship and generate a second verification track;

[0035] A verification module is configured to perform re-concurrent defect testing on the program under test using the second verification trace to identify whether there is an additional concurrent defect in the program under test.

[0036] The application further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the concurrent defect detection method based on read-write relationship according to any one of the above when executing the program.

[0037] The application further provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program is executable on a processor to implement the concurrent defect detection method based on read-write relationship according to any one of the above.

[0038] The application further provides a computer program product comprising a computer program, wherein the computer program is executable on a processor to implement the concurrent defect detection method based on read-write relationship according to any one of the above.

[0039] To sum up, the one or more technical solutions provided in the embodiments of the application have at least the following technical effects or advantages:

[0040] By obtaining the original trace, the known concurrent defect of the program under test can be reproduced, thereby providing a basic input for verifying the patch repair effect. By adjusting the thread scheduling order in the original trace to generate the first verification trace, the program behavior change after the patch is introduced can be adapted, while the feasibility of the execution path is maintained. By performing static analysis on the first verification trace, suspicious read-write relationships in the program can be accurately identified from the perspective of control flow and data flow. By constructing a static dependency graph and tracking a value dependency path, a key branch that may cause an exception and related read-write events can be located, thereby providing a clear basis for 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 to generate the second verification trace, more potential concurrent exception scenarios can be simulated. By performing re-concurrent defect testing on the program under test using the second verification trace, the patch repair effect can be comprehensively verified, and possible additional defects can be identified, thereby efficiently and comprehensively detecting and verifying whether there is an additional concurrent defect in a complex concurrent program. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0042] Figure 1Is one of the flowcharts of the concurrent defect detection method based on read-write relationship provided by the application.

[0043] Figure 2 Is the network architecture schematic diagram of the airport pavement performance prediction model provided by the application.

[0044] Figure 3 Is the second flowchart of the concurrent defect detection method based on read-write relationship provided by the application.

[0045] Figure 4 Is the third flowchart of the concurrent defect detection method based on read-write relationship provided by the application.

[0046] Figure 5 Is the fourth flowchart of the concurrent defect detection method based on read-write relationship provided by the application.

[0047] Figure 6 Is the structural schematic diagram of the concurrent defect detection system based on read-write relationship provided by the application.

[0048] Figure 7 Is the structural schematic diagram of the electronic device provided by the application. DETAILED DESCRIPTION

[0049] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below with reference to the drawings in the present application. Obviously, the described embodiments are some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the present application.

[0050] It should be noted that in the description of the present application, the terms "comprise", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "comprises a" does not exclude the presence of another identical element in the process, method, article or device comprising the element. The terms "upper", "lower" and the like indicate the orientation or positional relationship shown in the drawings, and are only used to facilitate the description of the present application and simplify the description, and do not indicate or imply that the indicated system or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0051] The terms "first", "second", etc. in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of a kind and do not limit the number of objects, 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 means that the objects before and after are in an "or" relationship.

[0052] The following will be described in conjunction with Figures 1-7 The read-write relationship based concurrent defect detection method, system, electronic device and storage medium provided by the present application are described.

[0053] Figure 1 is one of the flowcharts of the read-write relationship based concurrent defect detection method provided by the present application, as Figure 1 shown, including but not limited to the following steps:

[0054] Step 101: Obtain the original trajectory, which is used to trigger the known concurrent defect of the program under test.

[0055] In the implementation of step 101, first, the original trajectory τ0 needs to be obtained, which serves as the basis for triggering the known concurrent defect 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 and the key event information of each thread execution in the program execution process, and its significant feature is that it can reproduce the concurrent defect phenomenon of the program under test in the original state, thereby providing a clear reference for verifying the repair effect.

[0056] In order to obtain the original trajectory τ0, it is necessary to dynamically monitor and record the program under test P in its running environment. Specifically, by embedding the controller into the execution framework of the program under test, precise control of thread scheduling can be achieved. During program execution, the controller executes the operations of each thread according to the established scheduling logic, and records all thread execution events and their order through the recorder. The recorder captures the start, wait, end and other life cycle events of the thread, as well as the access (including read and write operations) of shared variables between threads, and completely reconstructs the running trajectory of the program.

[0057] The core of this recording method lies in the complete capture of thread scheduling behavior. The controller can not only reproduce the known thread execution order but also ensure the consistency of the trajectory τ0 across multiple experiments. This consistency is crucial for verifying the effectiveness of the patch, as random changes to the trajectory can lead to uncertainty in test results. Furthermore, the recording process marks key points that trigger concurrency defects during program execution, including but not limited to race conditions between threads, deadlock triggers, and data consistency issues, thereby clarifying the patch's objectives.

[0058] Step 102: Adjust the thread scheduling order in the original trajectory to generate the first verification trajectory.

[0059] In step 102, the first verification trajectory τ1 is generated by adjusting the thread scheduling order in the original trajectory τ0. The main purpose is to adapt to the changes in the program under test P after the patch fix, while ensuring the feasibility and completeness of the verification trajectory. Since the introduction of the patch may render the scheduling order or operations of some threads in the original trajectory τ0 infeasible, a new trajectory τ1 must be generated by rescheduling to cover possible execution paths, providing a reliable basis for static analysis and concurrent defect testing.

[0060] In one possible implementation, refer to Figure 2 , Figure 2 This is the second flowchart of the concurrent defect detection method based on read-write relationship provided by the present invention, as shown below. Figure 2 As shown, step 102 specifically includes steps 201-203:

[0061] Step 201: Exclude all threads that are blocked in the original trajectory and determine the first set of threads that can be executed at present.

[0062] In practice, the controller monitors the state of all threads in real time, determining whether a thread is blocked by checking if its running conditions are met. This determination is typically based on the thread's current events 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 is marked as blocked; if the thread can immediately execute the next event, it is marked as runnable. The controller adds all threads marked as runnable to the first thread set and removes all other blocked threads.

[0063] During the process of filtering threads, the controller dynamically updates the thread set by combining the event dependencies and resource occupation states of threads. For example, the executability of a thread may depend on the release of resources or the completion of operations by other threads. The controller recursively updates the thread states based on these dependencies to ensure the accuracy of the thread set. Meanwhile, the controller records the currently excluded blocked threads to reevaluate their states in subsequent scheduling processes.

[0064] Through this implementation process, step 201 can effectively reduce the uncertainty and unnecessary attempts in scheduling, improving the efficiency and success rate of overall scheduling. The effect of excluding blocked threads mainly manifests in the following aspects: first, it ensures that subsequent scheduling is only performed on currently executable threads, avoiding scheduling deadlocks or state unreachable problems caused by blocked threads. Second, this step narrows down the search space for thread scheduling, providing more accurate inputs for heuristic scheduling algorithms, thereby speeding up 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 of the program and the behavior after patching.

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

[0066] In specific implementation, the controller (Controller) scans all threads in the current first thread set, determines the earliest feasible event for each thread based on its event dependency relationship and resource usage state. This process relies on the event scheduling information of the thread, such as whether the next event of the thread depends on the execution result of other threads or 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.

[0067] After selecting and executing the thread, the controller updates the event queue of the thread, removing all infeasible events that are earlier than the current execution event. Infeasible events are usually caused by changes in scheduling logic or updates to program state, such as branch conditions being covered by new scheduling paths, thus no longer having executability. 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 states 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 true running state of the program.

[0068] In this way, step 202 can advance 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 multiple aspects: first, this scheduling strategy can prioritize exploring events on the critical path in the program, avoiding blocking subsequent scheduling due to the execution of low-priority events, thereby improving trajectory generation efficiency. Second, by removing infeasible events and dynamically refreshing the thread set, redundant attempts in scheduling can be significantly reduced, optimizing scheduling performance. In addition, the generated second thread set provides accurate thread scheduling basis for subsequent steps, ensuring the continuity of trajectory generation and the predictability of program behavior.

[0069] Step 203: Take the second thread set as the first thread set, and repeat the steps of selecting the thread with the earliest feasible event from the first thread set for execution, and after the execution of the thread, removing all infeasible events in the thread that are earlier than the current execution event, and refreshing the first thread set to generate the second thread set, until all threads are executed, and recording the complete execution trajectory of all threads during the execution process to generate the first verification trajectory.

[0070] In the specific implementation process, the controller (Controller) will initialize a new first thread set according to 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, the controller will update the event queue of the thread, remove the infeasible events, and recalculate the schedulability of all remaining threads to generate a new thread set. In each round of scheduling, the recorder (Recorder) synchronously records the thread identification 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.

[0071] During the loop scheduling process, the controller will also continuously check the execution status of all threads until the event queue of all threads is 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 trajectory τ1. This trajectory not only contains the scheduling order between threads, but also records the event execution of the thread and the access mode of the shared resource in detail, thereby fully reflecting the program behavior under the current scheduling strategy.

[0072] By implementing step 203, it can be ensured that the generated first verification track τ1 is complete and reproducible. This completeness is reflected in the following aspects: first, τ1 records the execution order and interaction information of all threads, which can truly reflect the current running logic of the program. Second, the cyclic scheduling method ensures that all thread events are fully executed, avoiding the situation that threads are missed due to improper scheduling. In addition, the generation of τ1 provides accurate and detailed basic data for the subsequent static analyzer (Static Analyzer), so that the static analysis can more accurately identify key branches and suspicious read-write relationships.

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

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

[0075] In one possible implementation, with reference to Figure 3 , Figure 3 is a flowchart of a read-write relationship-based concurrent defect detection method provided by the present application, as shown in Figure 3 , step 103 specifically includes steps 301-302:

[0076] Step 301: Determine the key branch in the first verification track, and the key branch is a branch that deviates from the normal control flow during execution.

[0077] In specific implementation, the static analyzer (Static Analyzer) first extracts the control flow information of the program from the first verification track τ1, including the branch jump record of the thread during runtime and the calculation result of the branch condition. The analyzer will traverse all events involving conditional judgment in the track and compare whether the actual execution path is consistent with the expected path. If the result of some branch condition does not conform to the logic of the normal running of the program, or the result of the condition causes the program to enter an abnormal state, such as deadlock, data race, etc., then the branch will be marked as a key branch.

[0078] To identify the critical branches more accurately, the static analyzer will analyze the key variables or operations that lead to the condition results in combination with the dependency relationship of each branch condition in the trace. For example, a branch condition may depend on the value of a global variable, and the static analyzer will trace back the source of the variable to locate the thread or event that affects its value. This process relies on the static dependency graph (SDG) that has been constructed in step 103 to describe the control and data dependency relationships between events in the program.

[0079] In locating the critical branches, the analyzer will also evaluate the abnormality and importance of the branches. For example, if the execution of a branch directly leads to the abnormal exit or inconsistent state of the program, the branch is marked as a critical branch in priority. At the same time, the analyzer will record the threads, events and condition variables related to the branch to provide detailed context information for subsequent analysis.

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

[0081] Step 302: Obtain suspicious read-write relationships according to the preset static dependency graph and critical branches.

[0082] In implementing step 302, it is necessary to construct suspicious read-write relationships according to the preset static dependency graph and critical branches. The core goal of this step is to use the static dependency structure of the program and the critical branch information extracted from the trace to accurately locate the key read-write events that lead to abnormal behavior and their dependency relationships, providing a basis for subsequent adjustment of thread interleaving order and verification of program behavior. Abnormalities in concurrent programs are usually caused by complex data races or control flow interference between threads, so in-depth analysis of read-write relationships is a key link to expose potential problems and optimize program design.

[0083] In one possible implementation, with reference to Figure 4 , Figure 4 is a flowchart of the read-write relationship-based concurrent defect detection method provided by the present application, as shown in Figure 4 , step 302 specifically includes steps 401-402:

[0084] Step 401: Trace the value dependency relationship path in the preset static dependency graph to identify at least one key read event in the critical branch that affects the critical branch, and the key write event corresponding to each key read event.

[0085] In implementation, the static analyzer first extracts the condition information of the key branch from the first verification trajectory τ1 and the static dependency graph (SDG). The condition of the key branch is usually based on the value of a variable or the result of a calculation, for example, a branch condition depends on the value of a global variable or the return value of a function. The static analyzer determines that the variable involved in the branch condition is a target variable that needs to be further analyzed by checking the variable.

[0086] Then, the analyzer uses the value dependency path recorded in the static dependency graph to perform reverse tracking on the target variable. The value dependency path describes the source of the variable value in the program and its propagation mode, for example, the value of a variable may come directly from the write operation of another thread, or it may be the result of indirect influence through function calls or intermediate variables. The analyzer traces back along the dependency path to identify all write events that can affect the current value of the target variable, and these events are marked as key write events. At the same time, the analyzer will mark the event of reading the value of the target variable as a key read event.

[0087] During the tracking process, in order to improve efficiency and focus on the root cause of the anomaly, the analyzer will preferentially track the nearest dependency path directly related to the key branch condition. For example, if the judgment of a branch condition depends on a global variable x, and the value of x is directly written by a thread in the current trajectory, the analyzer will preferentially mark this write event as a key write event, and ignore more distant potential influence events. This distance-based analysis strategy can effectively reduce the analysis range and avoid excessive expansion of the state space due to irrelevant events.

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

[0089] Step 402: Constructing suspicious read-write relationships according to all key read events and all key write events.

[0090] In implementation, the static analyzer (Static Analyzer) first receives the key read events and key write events identified in step 401, which are obtained by tracking the value dependency path in the static dependency graph and are directly related to the condition result of the key branch. The analyzer pairs each pair of key read-write events to determine their specific dependency relationship. For a key read event, the analyzer will locate all key write events that can affect its value and record the thread source, execution order, and operation mode of the variable of these events.

[0091] When constructing suspicious read-write relationships, the analyzer pays special attention to the following two types of dependencies:

[0092] Direct dependency: The result of a certain key write event is directly used in a key read event, such as the value of a global variable being read by other threads after being written.

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

[0094] To clearly express these dependencies, the analyzer generates description information for each pair of key read-write events, including the following:

[0095] Variable name: The identification of the global variable or shared resource being read or written.

[0096] Thread identification: The thread identifier that executes the read-write event.

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

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

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

[0100] 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 key events and their dependency paths that may cause anomalies, providing clear evidence for subsequent adjustments to thread interleaving order.

[0101] Step 104: According to the suspicious read-write relationships, adjust the thread interleaving order in the first verification trace to generate multiple second verification traces.

[0102] In implementing step 104, it is necessary to adjust the thread interleaving order in the first verification track according to the suspicious read-write relationship generated in step 103, to generate a plurality of second verification tracks τ2. The core goal of this step is to explore new execution paths that may cause program concurrency anomalies by changing the thread scheduling logic, so as to comprehensively verify the concurrency behavior of the program under test and evaluate the repair effect of the patch under different concurrency scenarios. Since the concurrency defects of the program are usually caused by specific thread interleaving orders, adjusting the thread interleaving order is an important method to expose potential problems and verify the correctness of the repair.

[0103] In one possible implementation, with reference to Figure 5 , Figure 5 Figure 5 is a flowchart of a read-write relationship-based concurrency defect detection method provided by the present application, as shown in Figure 5 step 104 specifically includes steps 501-504:

[0104] Step 501: Traverse all events in the first verification track and record the reachable dependent events in the first verification track.

[0105] In specific implementation, the trace generator (Trace Generator) is based on the first verification track τ1 and the suspicious read-write relationship generated in step 103, and uses the vector clock mechanism to perform dependency analysis on each event in the track. 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. The dependent events usually include the following categories: write events that update the value of a shared variable, read events that read the value of a shared variable, and events that have a direct impact on branch conditions.

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

[0107] Through this traversal and recording, the trace generator can not only clearly determine the dependency relationship 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 tracks in subsequent steps.

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

[0109] In implementation, the trace generator first maps each suspicious read-write relationship to the 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 positions in the trace and thread attribution. At the same time, the trace generator traces the dependency path of these events according to the causal relationship recorded by the vector clock, and marks all dependency events directly associated with them.

[0110] After determining the dependency events, the trace generator arranges them according to their execution order. The execution order is determined by the timestamps in the trace and the causal relationship between threads, ensuring that the order of dependency 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 record the write event first and associate it with the read event. In addition, the trace generator also handles cross-thread dependency relationships, ensuring that the order of cross-thread dependent events is accurately captured through vector clock comparison operations.

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

[0112] Step 503: Schedule each read-write event set corresponding to each dependency 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 the key read event in the read-write event set is scheduled after the key write event is scheduled.

[0113] In implementation, the Trace Generator adjusts the scheduling of each read-write event set based on the dependent events and their execution order recorded in step 502. The Trace Generator first selects a target read-write event set, identifies its corresponding key read event and key write event, and the dependent events associated with it. Then, according to the causal relationship marked by vector clocks, the dependent events are sorted to ensure that they have completed execution before the read-write events are scheduled, thus maintaining the logical consistency of events.

[0114] During scheduling, the Trace Generator prioritizes the scheduling of key write events because the execution of write events directly affects the value of key read events, which may change the logic of the program. After scheduling is complete, the Trace Generator marks the write event as completed and updates the status of its subsequent dependent events to confirm whether the key read event meets the execution conditions. When all dependent conditions of the key read event are met, the Trace Generator schedules the key read event and records its result in the trace.

[0115] To ensure the rationality of scheduling adjustment, the Trace Generator updates the thread state and schedulable event set in real time after each scheduling is completed. For example, when a certain key write event is completed, the read events in other threads that depend on this write event will be marked as schedulable, thus being prioritized in the next round of scheduling. Through this dynamic updating mechanism, the Trace Generator gradually completes the scheduling adjustment of all read-write event sets and finally generates a complete scheduling path.

[0116] This adjustment process aims to explore scenarios that may trigger concurrent defects in the program, so the Trace Generator monitors abnormal behavior in real time during scheduling. For example, if a scheduling adjustment leads to inconsistent values of shared resources or triggers a deadlock, the Trace Generator will record the abnormal information and mark the current scheduling path as a potential defect scenario. This information will be passed on to the subsequent testing stage to verify the effectiveness of patch repairs.

[0117] Step 504: After all read-write event sets are scheduled, generate multiple second verification traces according to the scheduling order of the threads.

[0118] In implementation, the Trace Generator integrates each event in the order of execution after completing the scheduling adjustment of all read-write event sets. This integration process needs to maintain the integrity of the program logic to ensure that the causal relationship between events and the dependent path between threads is 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 vector clocks. This sorting method can accurately capture the interaction logic across threads, such as the read event affected by a write event always occurring after it.

[0119] When generating the trace, the trace generator processes each event one by one, ensuring that its dependent events have been included in the previous part of the trace. For cross-thread dependencies, the trace generator ensures that the order of events complies with the inter-thread causal chain by comparing the timestamps and the values of the vector clocks. 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 inter-thread interaction logic while avoiding logical conflicts caused by scheduling adjustments.

[0120] After completing the global integration, the trace generator generates a plurality of second verification traces τ2 and compares them with the first verification trace τ1, recording the newly added thread interleaving scenarios and potential abnormal information. The generated τ2 not only covers the unexplored concurrent paths in the original trace, but also simulates more concurrent situations that may trigger exceptions by adjusting the scheduling order, providing more comprehensive data support for verifying the patch repair effect.

[0121] Step 105: Use all second verification traces to perform concurrent defect testing on the program under test to identify whether the program under test has additional concurrent defects.

[0122] In implementing step 105, the program under test P needs to be tested for concurrent defects using all second verification traces τ2 to identify whether the program has additional concurrent defects. The core goal of this step is to run the program in new thread interleaving scenarios to verify its behavior after patch repair and explore potential exceptions or boundary conditions. The introduction of the patch may have repaired known defects, but its impact on other thread interaction scenarios needs to be verified, so testing with τ2 can comprehensively evaluate the effectiveness and robustness of the patch.

[0123] In specific implementation, the controller (Controller) and the recorder (Recorder) work together to reproduce the execution order of τ2. The controller accurately controls the order of thread alternation execution according to the scheduling information of τ2, ensuring that the execution of each event strictly follows the dependency relationship and causal order in the trace. The recorder monitors the state changes in the program running process in real time, captures the execution information of threads, the access situation of shared resources, and potential abnormal information.

[0124] During the test, the controller will schedule each event in τ2 step by step and dynamically detect the running state of the program. For example, for events of reading and writing shared variables, the recorder checks whether there is a data race or a condition variable that is not satisfied. For branch conditions or lock mechanisms, the recorder analyzes whether the branch condition is triggered correctly or whether the lock causes thread 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 dependent events.

[0125] In a possible implementation, after step 105, the method further comprises the following steps:

[0126] When it is identified that the tested program has an additional concurrency defect, a second verification trace and the additional concurrency defect are recorded;

[0127] When it is identified that the tested program does not have an additional concurrency defect, it is determined that the concurrency defect corresponding to the tested program is correctly repaired.

[0128] 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 trigger the exception. The recorder also analyzes the set of read-write events related to the exception to extract the shared variables, thread identifiers and time sequence affected by the exception to form a complete exception description.

[0129] At the same time, the controller will perform backtracking analysis on the trigger path of the abnormal behavior, use vector clocks to confirm the causal relationship between the exception event and its dependent events, and ensure that the recorded exception information can accurately reflect the interaction logic between threads. All information related to the exception, including the exception type, trigger condition, involved event set and thread scheduling order, are stored as an exception report and recorded together with τ2. These reports provide a clear target for subsequent patch optimization, facilitating developers to analyze the causes of newly added defects and take repair measures.

[0130] When the concurrency defect test of the second verification trace τ2 does not find additional defects, it is confirmed that all thread interaction behaviors meet the expected logic of the program and do not trigger known or additional concurrency defects, confirming that the concurrency defect corresponding to the tested program has been correctly repaired, and the test results are summarized as a verification report, which includes effectiveness analysis of patch repair, concurrency scenario description of trace coverage, and performance evaluation of the program under multiple interaction logics.

[0131] Reference Figure 6 , Figure 6 is a structural schematic diagram of a concurrency defect detection system based on read-write relationship provided by the application, and the system comprises:

[0132] an acquisition module, configured to acquire an original track, the original track being used to trigger a known concurrent defect of a to-be-tested program;

[0133] a first track generation module, configured to adjust a thread scheduling sequence in the original track to generate a first verification track;

[0134] an analysis module, configured to perform static analysis on the first verification track and the to-be-tested program to obtain a suspicious read-write relationship;

[0135] a second track generation module, configured to adjust a thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate a second verification track;

[0136] a verification module, configured to perform re-concurrent defect testing on the to-be-tested program by using the second verification track to identify whether the to-be-tested program has an additional concurrent defect.

[0137] In a possible implementation, the first track generation module is further configured to:

[0138] exclude all threads in a blocking state in the original track to determine a first thread set that can be currently executed;

[0139] select a thread that schedules an earliest feasible event from the first thread set to perform, and after the thread is executed, remove all infeasible events that are earlier than a current execution event in the thread, and refresh the first thread set to generate a second thread set;

[0140] take the second thread set as the first thread set, and repeatedly perform the steps of selecting a thread that schedules an earliest feasible event from the first thread set to perform, and after the thread is executed, removing all infeasible events that are earlier than a current execution event in the thread, and refreshing the first thread set to generate a second thread set, until all threads are executed, and record complete execution tracks of all threads in the execution process to generate the first verification track.

[0141] In a possible implementation, the analysis module is further configured to:

[0142] determine a key branch in the first verification track, the key branch being a branch that deviates from a normal control flow in the execution process;

[0143] obtain the suspicious read-write relationship according to the preset static dependency graph and the key branch.

[0144] In a possible implementation, the analysis module is further configured to:

[0145] trace a value dependency relationship path in the preset static dependency graph to identify at least one key read event that has an impact on the key branch in the key branch, and a key write event corresponding to each key read event.

[0146] According to all key read events and all key write events, a suspicious read-write relationship is constructed.

[0147] In a possible implementation, the second trajectory generation module is further configured to:

[0148] All events in the first verification trajectory are traversed, and reachable dependent events in the first verification trajectory are recorded;

[0149] Dependent events corresponding to each read-write event set in the suspicious read-write relationship are determined, and an execution order of each dependent event is recorded; each read-write event set includes a key read event and a corresponding key write event;

[0150] According to the execution order, the read-write event set corresponding to each dependent event is scheduled, and a scheduled thread interleaving order is recorded; wherein, in the scheduling process of each read-write event set, the key write event in the read-write event set is preferentially scheduled, and the key read event in the read-write event set is scheduled after the scheduling of the key write event is completed;

[0151] After the scheduling of all read-write event sets is completed, the second verification trajectory is generated according to the scheduled thread interleaving order.

[0152] In a possible implementation, the verification module is further configured to:

[0153] When it is identified that the to-be-tested program has an additional concurrency defect, the second verification trajectory and the additional concurrency defect are recorded;

[0154] When it is identified that the to-be-tested program does not have an additional concurrency defect, when it is identified that the to-be-tested program does not have an additional concurrency defect, it is determined that the concurrency defect corresponding to the to-be-tested program is correctly repaired.

[0155] It should be noted that the concurrency defect detection system based on a read-write relationship provided in the present application can execute the concurrency defect detection method based on a read-write relationship in any of the above embodiments when specifically running, and the present embodiment will not be described here.

[0156] Figure 7 is a structural schematic diagram of an electronic device provided by the present application, such as Figure 7As shown, the electronic device can include a processor 710, a communications interface 720, a memory 730, and a communications bus 740, wherein the processor 710, the communications interface 720, and the memory 730 communicate with each other through the communications bus 740. The processor 710 can invoke a logical instruction in the memory 730 to execute a concurrent defect detection method based on a read-write relationship, which includes: obtaining an original trajectory, the original trajectory being used to trigger a known concurrent defect of a program under test; adjusting a 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 a thread interleaving order in the first verification trajectory according to the suspicious read-write relationship to generate a second verification trajectory; and performing re-concurrent defect testing on the program under test by using the second verification trajectory to identify whether the program under test has an additional concurrent defect.

[0157] In addition, the logical instruction in the memory 730 described above can be implemented in the form of a software functional unit and sold or used as an independent product, which can be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the embodiments of the method of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0158] On the other hand, the present application 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 concurrent defect detection method based on the read-write relationship provided by the above-mentioned embodiments, which includes: obtaining an original trajectory, the original trajectory being used to trigger a known concurrent defect of a program under test; adjusting a 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 a thread interleaving order in the first verification trajectory according to the suspicious read-write relationship to generate a second verification trajectory; and performing re-concurrent defect testing on the program under test by using the second verification trajectory to identify whether the program under test has an additional concurrent defect.

[0159] In yet another aspect, the present application also provides a non-transitory computer readable storage medium having stored thereon a computer program, which, when executed by the processor 710, implements the read-write relationship based concurrent defect detection method provided by the above embodiments, and the method comprises: obtaining an original trace, the original trace being used to trigger a known concurrent defect of a program under test; adjusting a thread scheduling sequence 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 suspicious read-write relationships; adjusting a thread interleaving sequence in the first verification trace according to the suspicious read-write relationships to generate a second verification trace; and performing re-concurrent defect testing on the program under test by using the second verification trace to identify whether the program under test has additional concurrent defects.

[0160] The system embodiments described above are merely illustrative, wherein the units illustrated as separate components can or can not be physically separate, and the components illustrated as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0161] Through the above description of the embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software and necessary universal hardware platforms, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of software products, which can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and include a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods of the embodiments or some parts of the embodiments.

[0162] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for detecting concurrency defects based on read-write relationships, the method comprising: The method comprises the following steps: ​ acquiring an original track for triggering a known concurrent defect of a program under test; adjusting a thread scheduling sequence in the original track to generate a first verification track; the adjusting a thread scheduling sequence in the original track to generate a first verification track specifically comprises: excluding all threads in a blocking state in the original track to determine a first thread set that can be executed at present; selecting a thread that schedules an earliest feasible event from the first thread set for execution, and after the execution of the thread is completed, removing all infeasible events earlier than a current execution event in the thread and refreshing the first thread set to generate a second thread set; taking the second thread set as the first thread set and repeatedly performing the steps of selecting a thread that schedules an earliest feasible event from the first thread set for execution, and after the execution of the thread is completed, removing all infeasible events earlier than a current execution event in the thread and refreshing the first thread set to generate a second thread set until all threads are executed, and recording complete execution tracks of all threads in the execution process to generate the first verification track; performing static analysis on the first verification track and the program under test to obtain a suspicious read-write relationship; adjusting a thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate a plurality of second verification tracks; the adjusting a thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate a plurality of second verification tracks specifically comprises: traversing all events in the first verification track and recording reachable dependent events in the first verification track; determining dependent events corresponding to each read-write event set in the suspicious read-write relationship and recording execution sequences of each dependent event; each read-write event set comprises a key read event and a corresponding key write event; scheduling each read-write event set corresponding to each dependent event according to the execution sequences and recording a thread interleaving sequence after scheduling; wherein in the scheduling process of each read-write event set, the key write event in the read-write event set is preferentially scheduled, and the key read event in the read-write event set is scheduled after the scheduling of the key write event is completed; after the scheduling of all read-write event sets is completed, generating a plurality of second verification tracks according to the thread interleaving sequence after scheduling; performing concurrent defect testing on the program under test again by using all second verification tracks to identify whether the program under test has additional concurrent defects.

2. The read-write relationship based concurrent defect detection method according to claim 1, wherein, The performing static analysis on the first verification track and the program under test to obtain a suspicious read-write relationship specifically comprises: determining a key branch in the first verification track, the key branch being a branch that must be met in the execution process to deviate from triggering a concurrent defect; obtaining the suspicious read-write relationship according to a preset static dependency graph and the key branch.

3. The read-write relationship based concurrent defect detection method according to claim 2, wherein, The obtaining the suspicious read-write relationship according to a preset static dependency graph and the key branch specifically comprises: tracking a value dependency path in a preset static dependency graph, identifying at least one key read event in the key branch that has an impact on the key branch and a key write event corresponding to each of the key read events; constructing a suspicious read-write relationship according to all the key read events and all the key write events.

4. The read-write relationship based concurrent defect detection method according to claim 1, wherein, The method further comprises: recording the second verification track and the additional concurrency defect when it is identified that the tested program has the additional concurrency defect; determining that the concurrency defect corresponding to the tested program is correctly repaired when it is identified that the tested program has no additional concurrency defect.

5. A concurrent defect detection system based on read-write relationship, characterized in that, comprise: an acquisition module configured to acquire an original track, the original track being used to trigger a known concurrency defect of a tested program; a first track generation module configured to adjust a thread scheduling sequence in the original track to generate a first verification track; the adjustment of the thread scheduling sequence in the original track to generate the first verification track specifically comprises: excluding all threads in a blocking state in the original track to determine a first thread set that is currently executable; selecting a thread that schedules an earliest feasible event from the first thread set for execution, and after the execution of the thread is completed, removing all infeasible events that are earlier than a current execution event in the thread, refreshing the first thread set to generate a second thread set; taking the second thread set as the first thread set and repeatedly performing the steps of selecting a thread that schedules an earliest feasible event from the first thread set for execution, and after the execution of the thread is completed, removing all infeasible events that are earlier than a current execution event in the thread, refreshing the first thread set to generate a second thread set until all threads are executed, and recording a complete execution track of all threads in the execution process to generate the first verification track; an analysis module configured to perform static analysis on the first verification track and the tested program to obtain a suspicious read-write relationship; a second track generation module configured to adjust a thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate a plurality of second verification tracks; the adjustment of the thread interleaving sequence in the first verification track according to the suspicious read-write relationship to generate the plurality of second verification tracks specifically comprises: traversing all events in the first verification track and recording reachable dependency events in the first verification track; determining dependency events corresponding to each read-write event set in the suspicious read-write relationship and recording an execution order of each of the dependency events; each of the read-write event sets comprises a key read event and a corresponding key write event; scheduling each of the read-write event sets corresponding to the dependency events according to the execution order and recording a thread interleaving sequence after the scheduling; wherein in the scheduling process of each of the read-write event sets, the key write event in the read-write event set is preferentially scheduled, and the key read event in the read-write event set is scheduled after the scheduling of the key write event is completed; after the scheduling of all the read-write event sets is completed, the plurality of second verification tracks are generated according to the thread interleaving sequence after the scheduling; A verification module is configured to perform a re-concurrent defect test on the program under test using all the second verification traces to identify whether there is an additional concurrent defect in the program under test.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The computer program is executed by the processor to implement the concurrent defect detection method based on read-write relationship according to any one of claims 1-4.

7. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the concurrent defect detection method based on read-write relationship according to any one of claims 1-4.

8. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the concurrent defect detection method based on read-write relationship according to any one of claims 1-4. The computer program is executed by the processor to implement the concurrent defect detection method based on read-write relationship according to any one of claims 1-4.

Images