Instrumented Process Debugging for Multi-Threaded Programs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing debugging techniques face challenges in efficiently locating and reproducing intermittent bugs in multi-threaded computer programs, particularly those that are not readily reproducible, due to issues like intermittent faults and non-deterministic behavior.
Innovation Solution
The method involves executing a system call in a multi-threaded computer program by generating an instrumented process that records operations, intercepts system calls, and delegates their execution back to the original thread to ensure correct behavior, allowing for accurate replay of program operations without serialization of threads and leveraging CPU optimizations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If threads are serialized for recording operations, then debugging accuracy is improved, but system productivity deteriorates due to loss of parallel execution
Solution Approach 1:
The system segments the multi-threaded program into separate thread recordings, capturing each thread's operations independently while preserving their individual execution contexts. This allows parallel threads to be recorded without serialization, maintaining productivity while enabling accurate debugging through separate replay capability.
Solution Approach 2:
An intermediary recording layer is introduced that captures thread operations without requiring thread serialization. The recording mechanism acts as a mediator between the executing threads and the debugging system, allowing threads to continue executing in parallel while their operations are being recorded for later analysis.
2Loss of information
If system calls are executed in the instrumented process, then recording completeness is improved, but system reliability deteriorates due to incorrect system call behavior
Solution Approach 1:
The system introduces an intermediary mechanism that intercepts system calls in the instrumented process and redirects them to the original uninstrumented process. This intermediary layer ensures that system calls execute with correct behavior in their original context while still allowing the instrumented process to record complete system call operations for debugging purposes.
Solution Approach 2:
Instead of having the instrumented process directly execute system calls (which causes reliability issues), the system inverts the execution flow by having the instrumented process record the system call parameters and then having the original process execute the actual system call. The results are captured and used to maintain recording completeness without compromising reliability.
3Productivity
If multiple second instrumented processes are generated per CPU core, then debugging efficiency is improved, but device complexity increases
Solution Approach 1:
The system applies local quality by creating second instrumented processes specifically targeted at each CPU core's workload characteristics. Each second instrumented process is optimized for the specific thread patterns and execution characteristics of its associated CPU core, improving debugging efficiency through localized optimization rather than uniform processing.
Solution Approach 2:
The system changes parameters such as CPU core association and thread affinity when generating second instrumented processes. By adjusting these parameters based on the specific debugging needs and system configuration, the system can optimize debugging efficiency while managing complexity through parameterized process generation rather than hard-coded configurations.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method of generating program analysis data for analysing the operation of a computer program. The method comprises, executing an instrumented process of the computer program to define a reference execution of the program, intercepting a call to a library function by the instrumented process, executing the library function in an uninstrumented process, for the uninstrumented process, capturing in a log, only data generated by or modified through the execution of the library function required by the instrumented process to continue execution of the program, and wherein the captured log is arranged to enable deterministically reproducing the effect of the library function call on the instrumented process upon re-running of the reference execution based upon the captured log to generate the program analysis data.