Debugging method for computer software development
By dynamically monitoring shared variables and building access history logs in multi-threaded software systems, the shortcomings of existing debugging methods in concurrent environments are resolved, enabling efficient error location and troubleshooting, and improving the reliability and stability of the software system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG SHISHU INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2026-03-13
- Publication Date
- 2026-06-19
AI Technical Summary
Existing debugging methods cannot accurately capture the instantaneous state of errors in multi-threaded software environments, lack shared variable history records, and make it difficult to trace the operation sequence and data dependencies between threads, resulting in difficulties in reproducing concurrent faults and low debugging efficiency.
By acquiring the target shared variable set of the concurrent software system, dynamic access monitoring is performed, capturing the thread identifier, variable identifier, value type, timestamp, and code location information of the access operation, constructing access history logs, reconstructing the historical value sequence of variables and the timing relationship of operations, and generating debugging alerts in combination with a preset pattern library.
It enables precise capture of instantaneous error states in a multi-threaded environment, clearly presents the causal chain of operations between threads, improves the accuracy and efficiency of concurrent software debugging, and ensures the reliability and stability of the system.
Smart Images

Figure CN122240452A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software development technology, specifically to debugging methods for computer software development. Background Technology
[0002] As the scale and complexity of computer software systems continue to grow, debugging, as a core element in ensuring software reliability and stability, is becoming increasingly important. Modern software development commonly employs high-level programming languages and modular architectures. Through traditional debugging methods such as breakpoint setting, variable monitoring, and single-step execution, developers can perform static snapshot-like analysis of the program's runtime state to locate logical errors or abnormal behavior. However, these methods are primarily designed for single-threaded or sequential execution models, and their effectiveness is significantly limited when facing highly concurrent software environments.
[0003] Multithreaded programming has become a mainstream paradigm for improving software performance and responsiveness. Multiple threads concurrently access and modify the same variable in a shared memory space to achieve efficient data interaction and task collaboration. In such scenarios, the correctness of the program depends not only on the completeness of the internal logic of each thread, but also on the temporal consistency of operations between threads and the control of data visibility.
[0004] Existing debugging methods suffer from the following drawbacks when dealing with multithreaded software: When a breakpoint is set at the target code location and execution is paused, the captured values of shared variables may have already been modified by other threads that are not synchronously blocked before or after the breakpoint is triggered, failing to accurately reflect the program state at the moment the error occurred. Furthermore, existing tools lack the ability to automatically record the historical value sequence of shared variables and cannot trace the timing of operations on the same variable by different threads or their causal relationships, making it difficult for developers to reconstruct the complete context in which the error occurred. Especially in sporadic failures caused by race conditions or data competition, these limitations make problem reproduction difficult, root cause location unclear, severely slowing down debugging efficiency and increasing software maintenance costs. Therefore, there is an urgent need for a software debugging method that can accurately capture the dynamic evolution of shared variables in a concurrent environment. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this invention provides a debugging method for computer software development, which solves the problems of traditional debugging methods in concurrent software debugging that cannot capture the instantaneous state of errors, lack shared variable history records, and have difficulty tracing the timing of operations and data dependencies between threads.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a debugging method for computer software development, comprising: S1. Obtain the target shared variable set in the concurrent software system of the computer to be debugged. The target shared variable set contains the identifiers of the shared variables to be tracked. S2. Perform dynamic access monitoring on each shared variable in the target shared variable set. Dynamic access monitoring includes: Automatically intercept access operations whenever a read or write operation occurs on a shared variable; For each intercepted access operation, capture the unique identifier of the current execution thread corresponding to the access operation, the unique identifier of the accessed shared variable, the current value of the shared variable when the access operation occurs, whether the access operation is a read operation or a write operation, the timestamp when the access operation occurs, and the program code location information where the access operation is located. S3. Encapsulate the captured access information into a shared variable access event record. The shared variable access event record contains the unique identifier of the current executing thread, the unique identifier of the accessed shared variable, the current value of the shared variable, the type of access operation, the timestamp, and the program code location information. S4. Serialize and store the shared variable access event records according to timestamps to build a shared variable access history log in the concurrent software system; S5. Based on the access history log of shared variables, analyze the access event records of shared variables in the log to reconstruct the historical value sequence of any specific shared variable in the concurrent software system, as well as the operation timing relationship and data dependency relationship of the shared variable between different execution threads.
[0007] Furthermore, obtaining the target set of shared variables in the concurrent computer software system to be debugged includes: Scan the source code or intermediate code of concurrent software systems to identify all variables declared as global variables or accessible by multiple threads; The scan results are parsed, and shared variable identifiers in the target shared variable set are selected according to preset filtering rules or user-specified conditions. The filtering rules include the access modifier of the variable, the memory region type of the variable, or the naming convention of the variable. The selected shared variable identifiers are registered in the debug monitoring module so that they can be identified and tracked by the dynamic access monitoring steps.
[0008] Furthermore, the dynamic access monitoring of each shared variable in the target shared variable set includes: During the loading or runtime of a concurrent software system, monitoring instructions or intercept hooks are injected into the target code of the concurrent software system. These monitoring instructions or intercept hooks are used to trigger events when shared variables are accessed. Alternatively, dynamic binary instrumentation can be used to insert additional instructions into the memory image of a concurrent software system without modifying the source code. These additional instructions are used to record access information when shared variables are accessed.
[0009] Furthermore, the unique identifier of the currently executing thread corresponding to the captured access operation includes: When an access operation occurs, query the thread management module of the concurrent software system runtime environment to obtain the system-level identifier of the thread currently executing the access operation; Get the user-defined name or logical identifier of the currently executing thread; Associating system-level identifiers with user-defined names creates a unique identifier for the currently executing thread.
[0010] Furthermore, the current value of the shared variable when the capture access operation occurs includes: When the access operation is a read access, the current data value of the shared variable in memory is read before or after the read operation is completed; When the access operation is a write access, the old data value of the shared variable is read before the write operation is completed, and the new data value of the shared variable is read after the write operation is completed. The read data values are associated with the type information of shared variables to ensure correct parsing and storage of the data values.
[0011] Furthermore, the step of serializing and storing the shared variable access event records according to precise timestamps includes: Each shared variable access event record is assigned a globally unique timestamp, which is generated using a high-precision system clock. Shared variable access events are continuously written to persistent storage media in the form of log files, with each record in the log file arranged in ascending order of timestamp.
[0012] Furthermore, the reconstructing of the historical value sequence of any specific shared variable in the concurrent software system includes: Filter out all access event records involving specific shared variables from the access history log; The selected access event records are sorted in ascending order according to their precise timestamps; Based on the sorted access event records, the value information of the shared variable at different time points is extracted to form an ordered value sequence, which reflects the evolution path of the shared variable from initialization to the current state.
[0013] Furthermore, the reconstructing of the timing relationship of the shared variable's operation between different execution threads in the concurrent software system includes: Identify the unique identifiers of all different execution threads that access shared variables from the access history logs; For each different execution thread, extract all access event records of its shared variables and sort them according to timestamp; The ordering access event records of different execution threads are merged, and a cross-thread access sequence diagram of shared variables is drawn based on timestamps. The sequence diagram shows when and how different threads access shared variables.
[0014] Furthermore, the reconstructing of the data dependencies of shared variables between different execution threads includes: In the access history log, identify event records that perform write operations on the same shared variable and their subsequent read operation event records; Tracing the causal chain between write operations and read operations that they directly or indirectly affect, the causal chain is determined by analyzing changes in the values of shared variables and the timing of operations; Construct a data flow graph for shared variables. The data flow graph shows how the value of a shared variable propagates from a write to a read by one or more threads, thereby revealing potential paths of data races or inconsistencies.
[0015] Furthermore, the shared variable access event records in the analysis log include: Based on the reconstructed historical value sequence of shared variables and the timing relationship of operations, as well as the pre-set concurrency problem pattern library, pattern matching analysis is performed. When the analysis results match any specific pattern in the concurrency problem pattern library, a corresponding debug alert is generated. The debug alert indicates potential data race, deadlock, livelock, or memory visibility issues. Output debug alerts, along with the shared variable access events that triggered the alerts and the stack information of the relevant threads, to the debug report or the debug interface of the integrated development environment.
[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention acquires the target shared variable set of a concurrent software system and performs dynamic access monitoring. It automatically intercepts variable read / write operations and corresponding thread identifiers, variable identifiers, value types, timestamps, and code location information without pausing threads. This solves the problem in traditional breakpoint debugging where other threads modify shared variables before and after a breakpoint is triggered, making it impossible to capture the instantaneous state of an error. The captured information is encapsulated as event records and serialized by timestamp to construct an access history log. Combined with log analysis, the historical value sequence of variables can be reconstructed, overcoming the lack of historical variable record capabilities in traditional methods. Simultaneously, it can clarify the temporal relationship and data dependency of different threads' operations on variables, clearly presenting the causal chain of operations between threads. This overcomes the difficulties in reproducing sporadic concurrent faults and the ambiguity in root cause localization. Furthermore, it can generate debugging alerts based on a preset concurrent problem pattern library, quickly identifying potential problems and improving the overall accuracy and efficiency of concurrent software debugging, effectively ensuring the reliability and stability of the concurrent software system. Attached Figure Description
[0017] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a flowchart of the dynamic access monitoring and event capture process of the present invention; Figure 3 This is a flowchart of the access history log analysis process of the present invention. Detailed Implementation
[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0019] Please see Figure 1-3 This invention provides a debugging method for computer software development, comprising: S1. Obtain the target shared variable set in the concurrent software system of the computer to be debugged. The target shared variable set contains the identifiers of the shared variables to be tracked. S2. Perform dynamic access monitoring on each shared variable in the target shared variable set. Dynamic access monitoring includes: Automatically intercept access operations whenever a read or write operation occurs on a shared variable; For each intercepted access operation, capture the unique identifier of the current execution thread corresponding to the access operation, the unique identifier of the accessed shared variable, the current value of the shared variable when the access operation occurs, whether the access operation is a read operation or a write operation, the timestamp when the access operation occurs, and the program code location information where the access operation is located. S3. Encapsulate the captured access information into a shared variable access event record. The shared variable access event record contains the unique identifier of the current executing thread, the unique identifier of the accessed shared variable, the current value of the shared variable, the type of access operation, the timestamp, and the program code location information. S4. Serialize and store the shared variable access event records according to timestamps to build a shared variable access history log in the concurrent software system; S5. Based on the access history log of shared variables, analyze the access event records of shared variables in the log to reconstruct the historical value sequence of any specific shared variable in the concurrent software system, as well as the operation timing relationship and data dependency relationship of the shared variable between different execution threads.
[0020] Specifically, when developing a concurrent order processing system for an e-commerce platform, the system frequently encountered intermittent data inconsistencies due to multiple threads simultaneously operating on order data. Traditional breakpoint debugging, by pausing a thread, allowed other threads to modify shared variables, failing to capture the instantaneous error state or trace the historical changes of variables and their temporal relationships with the threads. This method addresses this issue by first obtaining a set of target shared variables. Using static code analysis tools, the system source code and compiled intermediate code are traversed to identify variables accessible to multiple threads, such as order amount and order status, which are then designated as the target set of shared variables to be tracked. Next, dynamic access monitoring is performed on each target shared variable. When thread A performs a write operation on the order status or thread B performs a read operation on the order status, the system automatically intercepts the access operation and captures the thread's unique identifier, including the system-assigned thread PID and the user-defined business thread name, the unique ID of the accessed variable, the current value of the variable at the time of access, whether the operation type is read or write, the access timestamp generated by a high-precision system clock, and the corresponding code location, such as line 120 of the OrderService class. This captured information is then encapsulated into a shared variable access event log, ensuring that the log contains all key fields. The event records are then serialized and stored in persistent media in ascending order of timestamps to construct a complete access history log. Finally, based on log analysis, the historical value sequence of order status is reconstructed, clearly presenting the evolution path from initialization to pending payment and then to payment. At the same time, the timing relationship and data dependency relationship of different threads on this variable are sorted out, accurately locating the problem that thread B reads data before waiting for thread A to complete writing the order status. This solves the shortcomings of traditional debugging and greatly improves the accuracy and efficiency of concurrent error location and debugging.
[0021] In this embodiment, obtaining the target shared variable set in the concurrent software system of the computer to be debugged includes: Scan the source code or intermediate code of concurrent software systems to identify all variables declared as global variables or accessible by multiple threads; The scan results are parsed, and shared variable identifiers in the target shared variable set are selected according to preset filtering rules or user-specified conditions. The filtering rules include the access modifier of the variable, the memory region type of the variable, or the naming convention of the variable. The selected shared variable identifiers are registered in the debug monitoring module so that they can be identified and tracked by the dynamic access monitoring steps.
[0022] Specifically, taking the debugging of a concurrency module in a financial trading system as an example, an abstract syntax tree (AST) parser is first used to scan the module's source code and intermediate code, comprehensively identifying global variables declared as public and local variables stored in heap memory that can be accessed by multiple threads. Then, target shared variables are filtered according to preset filtering rules, excluding variables with private access modifiers and retaining heap memory variables. Variables that conform to naming conventions and begin with "trans" are also selected; these variables are often related to core trading data and are high-risk areas for concurrency issues. Finally, the selected variable identifiers are registered in the variable management list of the debugging and monitoring module through a configuration file, ensuring that the monitoring module can accurately identify and track these variables. This avoids resource waste caused by monitoring irrelevant variables and provides accurate tracking targets for subsequent dynamic monitoring, improving the targeting and efficiency of monitoring.
[0023] In this embodiment, dynamic access monitoring is performed on each shared variable in the target shared variable set, including: During the loading or runtime of a concurrent software system, monitoring instructions or intercept hooks are injected into the target code of the concurrent software system. These monitoring instructions or intercept hooks are used to trigger events when shared variables are accessed. Alternatively, dynamic binary instrumentation can be used to insert additional instructions into the memory image of a concurrent software system without modifying the source code. These additional instructions are used to record access information when shared variables are accessed.
[0024] Specifically, when debugging the concurrent message processing system of an instant messaging software, if the system is developed in Java, monitoring instructions are injected into the message processing-related target code using the JavaInstrumentation API during the system loading phase. When shared variables such as message queue length are accessed, the monitoring instructions immediately trigger events and notify the monitoring module. If the system is developed in C++ and the source code cannot be modified, the PIN dynamic binary instrumentation tool is used to insert additional instructions into its memory image during system runtime. These instructions automatically record access information and send it to the log module when variables such as message counters are read or written. This method does not require modification of the original business code, avoids introducing new errors, and can capture variable access operations in real time, ensuring the timeliness and completeness of monitoring, achieving effective debugging without affecting the normal operation of the system.
[0025] In this embodiment, the unique identifier of the currently executing thread corresponding to the access operation is captured, including: When an access operation occurs, query the thread management module of the concurrent software system runtime environment to obtain the system-level identifier of the thread currently executing the access operation; Get the user-defined name or logical identifier of the currently executing thread; Associating system-level identifiers with user-defined names creates a unique identifier for the currently executing thread.
[0026] Specifically, when debugging the multi-threaded task allocation module of a logistics dispatching system, when a thread accesses the shared variable of vehicle status, the monitoring module immediately queries the thread management module of the system runtime environment to obtain the system-level identifier of that thread, i.e., the thread ID assigned by the operating system. Simultaneously, it reads the user-defined name of the thread defined during development, such as TruckDispatchThread01, which directly reflects the thread's business function. Then, through the internal association logic of the monitoring module, the system-level thread ID is bound to the user-defined name, forming a unique identifier such as 1234-TruckDispatchThread01. This identifier balances system-level uniqueness with business-level readability, allowing developers to quickly associate threads with business functions when analyzing logs, improving problem analysis efficiency.
[0027] In this embodiment, capturing the current value of the shared variable when the access operation occurs includes: When the access operation is a read access, the current data value of the shared variable in memory is read before or after the read operation is completed; When the access operation is a write access, the old data value of the shared variable is read before the write operation is completed, and the new data value of the shared variable is read after the write operation is completed. The read data values are associated with the type information of shared variables to ensure correct parsing and storage of the data values.
[0028] Specifically, when debugging a shared inventory quantity variable in an e-commerce inventory management system, if a thread accesses it by reading, after the read operation is completed, the monitoring module directly reads the current data value of the variable in memory, such as 500 items, and associates it with the variable's integer type information to ensure that the stored data can be correctly parsed. If another thread accesses it by writing, before the write operation is executed, the monitoring module first reads the old data value of 500 items, and after the write is completed, it reads the new data value of 499 items, similarly associating it with integer type information for storage. This method completely records the current value of the read operation and the new and old values of the write operation, providing complete data for subsequent analysis of variable value changes, avoiding the problem of unclear variable evolution paths due to data gaps, and helping developers accurately trace the variable change process.
[0029] In this embodiment, the shared variable access event records are serialized and stored according to precise timestamps, including: Each shared variable access event record is assigned a globally unique timestamp, which is generated using a high-precision system clock. Shared variable access events are continuously written to persistent storage media in the form of log files, with each record in the log file arranged in ascending order of timestamp.
[0030] Specifically, when debugging the concurrent resource scheduling system of a cloud service platform, a globally unique timestamp is assigned to each shared variable access event record, and the basic time value is obtained using the CLOCK_MONOTONIC high-precision clock of the Linux system. Then through the formula Generate a timestamp. (The following is a list of steps...) A globally unique timestamp, in microseconds; The time value is obtained from a high-precision system clock, in microseconds. This is the offset coefficient, with a value of 1 microsecond / unit ID, used to prevent different threads from generating duplicate timestamps at the same time; This serves as a unique thread identifier and is dimensionless. Event records are then written to disk as log files, with each record strictly ordered by timestamp in ascending order. This method ensures unique and ordered timestamps, providing a reliable basis for subsequent time-based analysis of variable access events, avoiding temporal disorder, and improving the accuracy of log analysis.
[0031] Preferably, the value of α needs to be greater than 0, and in order not to significantly affect the actual time series, its maximum value should be much smaller than the interval between two meaningful timestamps, ensuring... The sorting is still mainly determined by Decide.
[0032] In this embodiment, reconstructing the historical value sequence of any specific shared variable in a concurrent software system includes: Filter out all access event records involving specific shared variables from the access history log; The selected access event records are sorted in ascending order according to their precise timestamps; Based on the sorted access event records, the value information of the shared variable at different time points is extracted to form an ordered value sequence, which reflects the evolution path of the shared variable from initialization to the current state.
[0033] Specifically, when analyzing the shared variable for message count in a concurrent message push system of a social platform, all event records containing this variable identifier were filtered from the access history logs. Then, a sorting algorithm was applied to arrange the records in ascending order of timestamps, ensuring consistency with the actual access order. Subsequently, the variable values at different time points were extracted from the sorted records. For example, an initial value of 0 becomes 10 after being written by thread A, remains 10 after being read by thread B, and becomes 15 after being written by thread C, forming an ordered value sequence. This sequence fully reflects the variable's evolution path, allowing developers to intuitively view value changes, quickly locate the time points of abnormal values, and improve the efficiency of concurrency problem localization.
[0034] In this embodiment, reconstructing the timing relationship of the operation of the shared variable between different execution threads in the concurrent software system includes: Identify the unique identifiers of all different execution threads that access shared variables from the access history logs; For each different execution thread, extract all access event records of its shared variables and sort them according to timestamp; The ordering access event records of different execution threads are merged, and a cross-thread access sequence diagram of shared variables is drawn based on timestamps. The sequence diagram shows when and how different threads access shared variables.
[0035] Specifically, when debugging a concurrent course registration system for an online education platform, for a shared variable indicating the maximum number of students allowed in a course, unique identifiers of threads accessing this variable were identified from the logs, such as EnrollThread01, EnrollThread02, and EnrollThread03. For each thread, its access records were extracted and sorted by timestamp; for example, the record order for EnrollThread01 was read operation, write operation, read operation. Then, the sorted records of all threads were merged, and a cross-thread access sequence diagram was drawn based on the timestamps using a visualization tool. The diagram clearly shows the access time and operation type of each thread. Developers can intuitively grasp the thread access order through the sequence diagram, quickly identify timing anomalies, such as the problem that a write operation by a certain thread is not perceived by subsequent read threads, thus improving the efficiency of concurrent timing problem analysis.
[0036] In this embodiment, reconstructing the data dependency relationship of shared variables between different execution threads includes: In the access history log, identify event records that perform write operations on the same shared variable and their subsequent read operation event records; Tracing the causal chain between write operations and read operations that they directly or indirectly affect, the causal chain is determined by analyzing changes in the values of shared variables and the timing of operations; Construct a data flow graph for shared variables. The data flow graph shows how the value of a shared variable propagates from a write to a read by one or more threads, thereby revealing potential paths of data races or inconsistencies.
[0037] Specifically, when analyzing a shared variable for concurrent transaction amounts in a payment system, write operations of this variable were identified from the logs, such as thread PayThread01 changing the amount from 100 to 200 in 500 microseconds, and subsequent read operations, such as thread CheckThread01's read operation in 800 microseconds. By analyzing the variable's value changes and the timing of the operations, the causal chain between them was traced, determining that the 200 read by CheckThread01 originated from a write operation by PayThread01. A data flow graph was then constructed, with nodes representing thread operations and arrows indicating the direction of data propagation, illustrating the path of data propagation between threads. Developers can clearly identify potential paths of data contention using the data flow graph, reducing the risk of data inconsistency.
[0038] In this embodiment, analyzing the shared variable access event records in the log includes: Based on the reconstructed historical value sequence of shared variables and the timing relationship of operations, as well as the pre-set concurrency problem pattern library, pattern matching analysis is performed. When the analysis results match any specific pattern in the concurrency problem pattern library, a corresponding debug alert is generated. The debug alert indicates potential data race, deadlock, livelock, or memory visibility issues. Output debug alerts, along with the shared variable access events that triggered the alerts and the stack information of the relevant threads, to the debug report or the debug interface of the integrated development environment.
[0039] Specifically, when debugging a game server's concurrent player scoring system, the system performs pattern matching analysis based on the reconstructed historical value sequence of scoring variables and the timing relationship of operations, combined with a pre-defined concurrency problem pattern library. This library includes patterns such as data races and deadlocks. When it is found that the scoring variable is simultaneously written to by threads AddScoreThread and ReduceScoreThread, a data race pattern is matched, and the system generates a debug alert, indicating the potential problem and related thread and variable information. Simultaneously, the event log and thread stack information triggered by the alert are output to the debug report and the integrated development environment (IDE) debugging interface. Developers can quickly locate problems based on the alert without manually traversing logs, improving the efficiency of concurrency problem troubleshooting and ensuring server stability.
[0040] In summary, this invention acquires the target shared variable set of a concurrent software system and performs dynamic access monitoring. It automatically intercepts variable read / write operations and corresponding thread identifiers, variable identifiers, value types, timestamps, and code location information without pausing threads. This solves the problem in traditional breakpoint debugging where other threads modify shared variables before and after a breakpoint trigger, making it impossible to capture the instantaneous state of an error. The captured information is encapsulated as event records and serialized by timestamp to construct an access history log. Combined with log analysis, the historical value sequence of variables can be reconstructed, overcoming the deficiency of traditional methods in lacking variable history recording capabilities. Simultaneously, it can clarify the temporal relationship and data dependency relationship of different threads' operations on variables, clearly presenting the causal chain of operations between threads, overcoming the difficulty in reproducing occasional concurrent faults and the ambiguity in root cause localization. Furthermore, it can generate debugging alerts based on a preset concurrent problem pattern library, quickly identifying potential problems and improving the overall accuracy and efficiency of concurrent software debugging, effectively ensuring the reliability and stability of the concurrent software system.
[0041] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0042] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A debugging method for computer software development, characterized in that, include: S1. Obtain the target shared variable set in the concurrent software system of the computer to be debugged. The target shared variable set contains the identifiers of the shared variables to be tracked. S2. Perform dynamic access monitoring on each shared variable in the target shared variable set. Dynamic access monitoring includes: Automatically intercept access operations whenever a read or write operation occurs on a shared variable; For each intercepted access operation, capture the unique identifier of the current execution thread corresponding to the access operation, the unique identifier of the accessed shared variable, the current value of the shared variable when the access operation occurs, whether the access operation is a read operation or a write operation, the timestamp when the access operation occurs, and the program code location information where the access operation is located. S3. Encapsulate the captured access information into a shared variable access event record. The shared variable access event record contains the unique identifier of the current executing thread, the unique identifier of the accessed shared variable, the current value of the shared variable, the type of access operation, the timestamp, and the program code location information. S4. Serialize and store the shared variable access event records according to timestamps to build a shared variable access history log in the concurrent software system; S5. Based on the access history log of shared variables, analyze the access event records of shared variables in the log to reconstruct the historical value sequence of any specific shared variable in the concurrent software system, as well as the operation timing relationship and data dependency relationship of the shared variable between different execution threads.
2. The debugging method for computer software development according to claim 1, characterized in that, The acquisition of the target shared variable set in the concurrent software system of the computer to be debugged includes: Scan the source code or intermediate code of concurrent software systems to identify all variables declared as global variables or accessible by multiple threads; The scan results are parsed, and shared variable identifiers in the target shared variable set are selected according to preset filtering rules or user-specified conditions. The filtering rules include the access modifier of the variable, the memory region type of the variable, or the naming convention of the variable. The selected shared variable identifiers are registered in the debug monitoring module so that they can be identified and tracked by the dynamic access monitoring steps.
3. The debugging method for computer software development according to claim 1, characterized in that, The dynamic access monitoring of each shared variable in the target shared variable set includes: During the loading or runtime of a concurrent software system, monitoring instructions or intercept hooks are injected into the target code of the concurrent software system. These monitoring instructions or intercept hooks are used to trigger events when shared variables are accessed. Alternatively, dynamic binary instrumentation can be used to insert additional instructions into the memory image of a concurrent software system without modifying the source code. These additional instructions are used to record access information when shared variables are accessed.
4. The debugging method for computer software development according to claim 1, characterized in that, The unique identifier of the currently executing thread corresponding to the captured access operation includes: When an access operation occurs, query the thread management module of the concurrent software system runtime environment to obtain the system-level identifier of the thread currently executing the access operation; Get the user-defined name or logical identifier of the currently executing thread; Associating system-level identifiers with user-defined names creates a unique identifier for the currently executing thread.
5. The debugging method for computer software development according to claim 1, characterized in that, The current value of the shared variable when the capture access operation occurs includes: When the access operation is a read access, the current data value of the shared variable in memory is read before or after the read operation is completed; When the access operation is a write access, the old data value of the shared variable is read before the write operation is completed, and the new data value of the shared variable is read after the write operation is completed. The read data values are associated with the type information of shared variables to ensure correct parsing and storage of the data values.
6. The debugging method for computer software development according to claim 1, characterized in that, The step of serializing and storing shared variable access event records according to precise timestamps includes: Each shared variable access event record is assigned a globally unique timestamp, which is generated using a high-precision system clock. Shared variable access events are continuously written to persistent storage media in the form of log files, with each record in the log file arranged in ascending order of timestamp.
7. The debugging method for computer software development according to claim 1, characterized in that, The reconstructed historical value sequence of any specific shared variable in the concurrent software system includes: Filter out all access event records involving specific shared variables from the access history log; The selected access event records are sorted in ascending order according to their precise timestamps; Based on the sorted access event records, the value information of the shared variable at different time points is extracted to form an ordered value sequence, which reflects the evolution path of the shared variable from initialization to the current state.
8. The debugging method for computer software development according to claim 1, characterized in that, The reconstructed concurrent software system includes the following: the timing relationship of the operation of the shared variable between different execution threads. Identify the unique identifiers of all different execution threads that access shared variables from the access history logs; For each different execution thread, extract all access event records of its shared variables and sort them according to timestamp; The ordering access event records of different execution threads are merged, and a cross-thread access sequence diagram of shared variables is drawn based on timestamps. The sequence diagram shows when and how different threads access shared variables.
9. The debugging method for computer software development according to claim 1, characterized in that, The reconstructing of the data dependencies of shared variables across different execution threads includes: In the access history log, identify event records of write operations to the same shared variable and their subsequent read operation event records; Tracing the causal chain between write operations and read operations that they directly or indirectly affect, the causal chain is determined by analyzing changes in the values of shared variables and the timing of operations; Construct a data flow graph for shared variables. The data flow graph shows how the value of a shared variable propagates from a write to a read by one or more threads, thereby revealing potential paths of data races or inconsistencies.
10. The debugging method for computer software development according to claim 1, characterized in that, The shared variable access event records in the analysis log include: Based on the reconstructed historical value sequence of shared variables and the timing relationship of operations, as well as the pre-set concurrency problem pattern library, pattern matching analysis is performed. When the analysis results match any specific pattern in the concurrency problem pattern library, a corresponding debug alert is generated. The debug alert indicates potential data race, deadlock, livelock, or memory visibility issues. Output debug alerts, along with the shared variable access events that triggered the alerts and the stack information of the relevant threads, to the debug report or the debug interface of the integrated development environment.