A software defect location method and system based on multiple dynamic program execution trajectories

Abstract

The present application discloses a software defect location method and system based on multiple dynamic program execution traces. The method captures the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case; according to the first time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case are vectorized to obtain a first time series vector sequence; the first time series vector sequence is input into a trained defect location model to obtain the probability of each first time step containing a defect; according to the probability of each first time step containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case, a defect location report is determined. The present application can capture the complex multi-dimensional dynamic behavior of the program during operation and improve the accuracy of software defect location.

Description

Technical Field

[0001] The present application relates to the technical field of software defect location, and in particular to a software defect location method and system based on multiple dynamic program execution trajectories. Background Art

[0002] Existing defect localization techniques usually rely on a single data source during program execution, such as code coverage, test case results, or mutation testing. Although this method can provide suspicion calculation for code lines, it is difficult to capture the complex multi-dimensional dynamic behavior of the program during operation due to the single source of information. The multi-dimensional dynamic behavior includes the dynamic behavior of register information, heap information, stack information, and instruction information generated by the program during operation. Especially when dealing with complex systems or multi-threaded concurrent environments, these technologies are prone to miss fine-grained defects, resulting in insufficient accuracy in suspicion calculation, which affects the accuracy of defect localization. Summary of the invention

[0003] This application aims to propose a software defect location method and system based on multi-dynamic program execution trajectories, which can capture the complex multi-dimensional dynamic behavior of the program during operation and improve the accuracy of software defect location.

[0004] In a first aspect, an embodiment of the present application provides a software defect location method based on multiple dynamic program execution traces, the method comprising:

[0005] Obtaining source code of a defect to be located and a test case corresponding to the source code of the defect to be located;

[0006] Capturing register traces, heap traces, stack traces, and instruction traces generated when the source code of the defect to be located executes the test case;

[0007] According to the first time step, vectorize the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is one of the first time steps;

[0008] Inputting the first time series vector sequence into a trained defect localization model to obtain the probability of each of the first time steps containing a defect;

[0009] A defect location report is determined according to the probability of each of the first time steps containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0010] Compared with the prior art, the first aspect of the present application has the following beneficial effects:

[0011] The method captures the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case; according to the first time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case are vectorized to obtain a first time sequence vector sequence, wherein each instruction executed by the source code of the defect to be located is a first time step; the first time sequence vector sequence is input into the trained defect location model to obtain the probability of each first time step containing a defect; the defect location report is determined according to the probability of each first time step containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case. In this way, by capturing the complex multi-dimensional dynamic behavior of the program during execution, the fusion of different trajectory information can help locate a wider range of types of defects, rather than being limited to a single-dimensional analysis, and can improve the accuracy of software defect location.

[0012] In some implementations, the trained defect localization model is obtained by:

[0013] Acquire a software defect location dataset, wherein the software defect location dataset includes source codes of multiple projects and test cases corresponding to the source codes of each of the projects;

[0014] Capturing register traces, heap traces, stack traces, and instruction traces generated when the source code of each of the items in the software defect location data set executes a test case;

[0015] According to the second time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of each of the projects executes the test case are vectorized to obtain a second timing vector sequence set, wherein each instruction executed by the source code of each of the projects is one second time step;

[0016] The constructed defect localization model is trained using the second time series vector sequence set to obtain a trained defect localization model.

[0017] In some implementations, obtaining a software defect location dataset includes:

[0018] Collect source code, test cases, documents, submission history, and pull requests of projects on code hosting platforms;

[0019] Determine the number and location of defects based on the pull request;

[0020] A software defect location dataset is constructed based on the defect quantity, the defect location, the source code, the test case, the document, and the submission history.

[0021] In some embodiments, the trained defect localization model includes an input embedding layer, a position encoding layer, a plurality of stacked encoding layers, a fully connected layer, and an activation function, and the first time series vector sequence is input into the trained defect localization model to obtain a defect localization result corresponding to each time step, including:

[0022] Inputting the first time series vector sequence into the input embedding layer to obtain an input embedding vector;

[0023] Inputting the input embedding vector into the position encoding layer for position encoding to obtain a position encoded vector;

[0024] Inputting the position-encoded vector into a first encoding layer to obtain an output result of the first encoding layer;

[0025] Using the output result of the first coding layer as the input of the next coding layer connected to the first coding layer, until all coding layers are coded, thereby obtaining a final result after the coding of multiple stacked coding layers is completed;

[0026] Inputting the final result into the fully connected layer to obtain the result output by the fully connected layer;

[0027] The activation function is used to normalize the result output by the fully connected layer to obtain the defect location result corresponding to each time step.

[0028] In some implementations, the register trace, stack trace, stack trace, and instruction trace generated when the source code of the defect to be located executes the test case includes:

[0029] The QEMU virtualization platform and the GDB debugger are used to capture the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0030] In some implementations, vectorizing the register trace, the stack trace, the stack trace, and the instruction trace information generated when the source code of the defect to be located executes the test case according to the first time step to obtain the first timing vector sequence includes:

[0031] Divide a first time step into each instruction executed according to the source code of the defect to be located, and obtain multiple first time steps;

[0032] Converting register traces, heap traces, stack traces, and instruction trace information generated when executing a test case on the source code of the defect to be located in each of the first time steps into vectorized form to obtain a first timing vector corresponding to each of the first time steps;

[0033] The first time series vectors corresponding to each of the first time steps are arranged in time order to obtain a first time series vector sequence.

[0034] In some implementations, determining a defect location report according to the probability of each of the first time steps containing a defect and the register trace, the stack trace, the stack trace, and the instruction trace generated when the source code of the defect to be located executes the test case includes:

[0035] Locate each line of code of the source code of the defect to be located according to the register trace, the stack trace, the stack trace and the instruction trace generated when the test case is executed in the source code of the defect to be located in each of the first time steps;

[0036] Each line of code in each of the first time steps is matched with the probability of containing a defect in each of the first time steps to generate a defect location report.

[0037] In a second aspect, an embodiment of the present application further provides a software defect localization system based on multiple dynamic program execution trajectories, the system comprising:

[0038] A data acquisition unit, used to acquire the source code of the defect to be located and the test case corresponding to the source code of the defect to be located;

[0039] A trace capture unit, used to capture register traces, heap traces, stack traces and instruction traces generated when the source code of the defect to be located executes the test case;

[0040] a vectorization unit, configured to vectorize register traces, heap traces, stack traces, and instruction trace information generated when the source code of the defect to be located executes the test case according to the first time step, to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is one of the first time steps;

[0041] A probability obtaining unit, used for inputting the first time series vector sequence into a trained defect localization model to obtain the probability of each of the first time steps containing a defect;

[0042] The defect location unit is used to determine a defect location report according to the probability of each of the first time steps containing defects and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0043] In the third aspect, an embodiment of the present application also provides an electronic device, comprising at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute a software defect location method based on multiple dynamic program execution trajectories as described above.

[0044] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute a software defect location method based on multiple dynamic program execution trajectories as described above.

[0045] It can be understood that the beneficial effects of the second to fourth aspects compared with the related art are the same as the beneficial effects of the first aspect compared with the related art. Please refer to the relevant description in the first aspect, and no further details will be given here. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0047] Figure 1 It is a flowchart of an embodiment of a software defect location method based on multiple dynamic program execution traces provided by the present application;

[0048] Figure 2 It is a schematic diagram of a data set generation process in a best embodiment of a software defect location method based on multiple dynamic program execution traces provided by the present application;

[0049] Figure 3 It is a schematic diagram of the overall structure of the best embodiment of the software defect location method based on multiple dynamic program execution traces provided by the present application;

[0050] Figure 4 It is a schematic diagram of the trajectory capture process in the best embodiment of the software defect location method based on multiple dynamic program execution trajectories provided by the present application;

[0051] Figure 5 It is a schematic diagram of the Transformer model architecture in the best embodiment of the software defect localization method based on multiple dynamic program execution traces provided by the present application;

[0052] Figure 6 It is a defect location flow diagram in the best embodiment of the software defect location method based on multiple dynamic program execution traces provided by the present application;

[0053] Figure 7 It is a structural diagram of an embodiment of a software defect localization system based on multiple dynamic program execution traces provided by the present application;

[0054] Figure 8 It is a schematic diagram of the structure of an embodiment of the electronic device provided by the present application. DETAILED DESCRIPTION

[0055] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limiting the present application.

[0056] In the description of this application, if there is a description of first, second, etc., it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0057] In the description of the present application, it should be understood that the descriptions involving orientation, such as the orientation or positional relationship indicated as up, down, etc., are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0058] In the description of this application, it should be noted that, unless otherwise clearly defined, terms such as setting, installing, connecting, etc. should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meaning of the above terms in this application based on the specific content of the technical solution.

[0059] Existing defect localization techniques usually rely on a single data source during program execution, such as code coverage, test case results, or mutation testing. Although this method can provide suspicion calculation for code lines, it is difficult to capture the complex multi-dimensional dynamic behavior of the program during operation due to the single source of information. Especially when dealing with complex systems or multi-threaded concurrent environments, these techniques are prone to miss fine-grained defects, resulting in insufficient accuracy in suspicion calculation, which affects the accuracy of defect localization.

[0060] In order to solve the above-mentioned problem that due to a single information source, it is difficult to capture the complex multi-dimensional dynamic behavior of the program during operation, resulting in insufficient precision in suspicion calculation, thereby affecting the accuracy of defect location, this application proposes a software defect location method and system based on multi-dynamic program execution trajectories.

[0061] Reference Figure 1The embodiment of the present application provides a software defect location method based on multiple dynamic program execution traces. The software defect location method based on multiple dynamic program execution traces is applied to an electronic device, which may be a server or a mobile terminal. The software defect location method based on multiple dynamic program execution traces includes the following steps:

[0062] Step S100: obtaining source code of a defect to be located and a test case corresponding to the source code of the defect to be located;

[0063] Step S200, capturing register traces, heap traces, stack traces and instruction traces generated when the source code of the defect to be located executes the test case;

[0064] Step S300: according to the first time step, vectorize the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is a first time step;

[0065] Step S400, inputting the first time series vector sequence into the trained defect location model to obtain the probability of containing defects in each first time step;

[0066] Step S500: Determine a defect location report according to the probability of each first time step containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0067] In this embodiment, the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case are captured; according to the first time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case are vectorized to obtain a first timing vector sequence, wherein each execution of an instruction by the source code of the defect to be located is a first time step; the first timing vector sequence is input into the trained defect location model to obtain the probability of each first time step containing a defect; the defect location report is determined according to the probability of each first time step containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case. In this way, by capturing the complex multi-dimensional dynamic behavior of the program during execution, the fusion of different trajectory information can help locate a wider range of types of defects, rather than being limited to a single-dimensional analysis, and can improve the accuracy of software defect location.

[0068] The source code of the defect to be located may be the source code of the software defect to be located.

[0069] The register trace, stack trace, stack trace and instruction trace generated when the source code of the defect to be located is executed in the test case can be an input test case, and the trace information of the source code of the defect to be located is captured by using the QEMU virtualization platform and the GDB debugger, so as to obtain the register trace, stack trace, stack trace and instruction trace generated when the source code of the defect to be located is executed in the test case.

[0070] The above-mentioned capture register trace may be the state of the capture register. A register is a hardware component used by the CPU to store temporary data when a program is executed. The state of the register directly reflects the operation currently executed by the program, including calculations, memory accesses, and changes in control flow.

[0071] The above-mentioned captured heap trace can be used to capture the allocation and release of heap memory. Heap memory is the area where the program dynamically allocates and releases memory, and is usually used to manage data objects during program runtime. Improper management of heap memory may lead to memory leaks or other errors. Therefore, capturing the allocation and release of heap memory is a key step in analyzing the program's memory management behavior.

[0072] The captured stack trace can be captured stack information. The stack is used to store function calls, parameters and local variables, and is the core of the function call chain. By capturing the stack information, the order of function calls in the program, the recursive depth and the storage of local variables can be understood.

[0073] The above-mentioned captured instruction trace can be to capture and analyze the instruction stream of the program. Instruction information is the lowest level of expression when the program is running, which records the specific execution of each step of the operation. By capturing and analyzing the instruction stream of the program, developers can understand the specific behaviors of the program such as control flow, data flow, memory operation, etc.

[0074] The above-mentioned vectorization may refer to converting the data of each time step into a vector representation of a fixed length so that the defect location model can process it.

[0075] In some implementations, the trained defect localization model is obtained by:

[0076] Obtain a software defect location dataset, where the software defect location dataset includes source codes of multiple projects and test cases corresponding to the source codes of each project;

[0077] Capture the register trace, heap trace, stack trace and instruction trace generated when the source code of each project in the software defect location dataset executes the test case;

[0078] According to the second time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of each project executes the test case are vectorized to obtain a second timing vector sequence set, wherein each instruction executed by the source code of each project is a second time step;

[0079] The constructed defect localization model is trained using the second time series vector sequence set to obtain a trained defect localization model.

[0080] In this embodiment, the register trace, heap trace, stack trace and instruction trace generated when the source code of each project in the software defect location data set executes the test case are captured; according to the second time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of each project executes the test case are vectorized to obtain a second timing vector sequence set, wherein each instruction executed by the source code of each project is a second time step; the constructed defect location model is trained using the second timing vector sequence set to obtain a trained defect location model. In this way, by combining the register trace, heap trace, stack trace and instruction trace to train the constructed defect location model, the complex behavior differences during program runtime can be captured more comprehensively, especially in processing dynamic memory allocation, recursive calls, register state changes, etc. It can improve the accuracy of defect location, thereby improving the accuracy of model location.

[0081] The defect localization model constructed above may include an input embedding layer, a position encoding layer, and a multi-head self-attention mechanism (i.e. Figure 3 The defect localization model is composed of multi-head attention layers in , feed-forward network layers, addition and normalization layers, fully connected layers, and activation functions.

[0082] In some implementations, obtaining a software defect localization dataset includes:

[0083] Collect source code, test cases, documents, submission history, and pull requests of projects on code hosting platforms;

[0084] Determine the number and location of defects based on the pull request;

[0085] Construct a software defect location dataset based on the number of defects, defect locations, source code, test cases, documents, and submission history.

[0086] In this embodiment, since the defect location method of this embodiment requires the software to be an executable project and the labels are more complex, it cannot be directly generated through existing data sets. Therefore, this embodiment collects source code, test cases, documents, submission history, and pull requests on the code hosting platform; according to the pull request, the number of defects and defect locations are determined; based on the number of defects, defect locations, source code, test cases, documents, and submission history, a software defect location data set is constructed. In this way, by collecting executable software projects, a good data foundation is laid for the later training of a defect location model capable of defect location.

[0087] In some embodiments, the trained defect localization model includes an input embedding layer, a position encoding layer, a plurality of stacked encoding layers, a fully connected layer, and an activation function. The first time series vector sequence is input into the trained defect localization model to obtain a defect localization result corresponding to each time step, including:

[0088] Input the first time series vector sequence into the input embedding layer to obtain an input embedding vector;

[0089] Input the input embedding vector into the position encoding layer for position encoding to obtain the position encoded vector;

[0090] Inputting the position-encoded vector into the first encoding layer to obtain the output result of the first encoding layer;

[0091] The output result of the first coding layer is used as the input of the next coding layer connected to the first coding layer, until the coding of all coding layers is completed, thereby obtaining a final result after the coding of multiple stacked coding layers is completed;

[0092] Input the final result into the fully connected layer to obtain the output of the fully connected layer;

[0093] The activation function is used to normalize the output of the fully connected layer to obtain the defect location result corresponding to each time step.

[0094] In this embodiment, position encoding is added to the input data to ensure that the model can capture the time dependency of the input sequence, and the dependency between different time steps in the input sequence is captured through a multi-head self-attention mechanism. The output is the context vector of each time step, which can better interpret the context information, thereby improving the positioning accuracy of the defect localization model.

[0095] The plurality of stacked encoding layers may be a plurality of encoding layers connected in series, wherein each encoding layer includes a multi-head self-attention mechanism and a feedforward network.

[0096] The above-mentioned input of the position-encoded vector into the first encoding layer to obtain the output result of the first encoding layer can be that the position-encoded vector is input into the multi-head self-attention mechanism in the first encoding layer to obtain multiple attention mechanism output results; the multiple attention mechanism output results are added and normalized with the position-encoded vector to obtain the first result; the first result is input into the feedforward network to obtain the result output by the feedforward network; the result output by the feedforward network and the first result are added and normalized to obtain the second result.

[0097] In the above, the output result of the first coding layer is used as the input of the next coding layer connected to the first coding layer until the coding of all coding layers is completed, and the final result after the coding of multiple stacked coding layers is completed is obtained. The second result may be input into the next coding layer connected to the first coding layer, and the output result of the coding layer is obtained after the multi-head self-attention mechanism, addition and normalization, and feedforward network processing that are the same as those of the first coding layer, and then the output result of the coding layer is used as the input of the next coding layer connected to the coding layer, and so on until the coding of all coding layers is completed, and the final result after the coding of multiple stacked coding layers is completed is obtained.

[0098] In some implementations, capturing register traces, heap traces, stack traces, and instruction traces generated when executing test cases in source code for defects to be located includes:

[0099] The QEMU virtualization platform and GDB debugger are used to capture the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0100] In this embodiment, the QEMU virtualization platform and the GDB debugger are used to well capture the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case, laying a good data foundation for the defect location model trained later to locate the defect.

[0101] In some implementations, according to the first time step, register traces, heap traces, stack traces, and instruction trace information generated when the source code of the defect to be located executes the test case are vectorized to obtain a first timing vector sequence, including:

[0102] According to the source code of the defect to be located, each execution of an instruction is divided into a first time step, and a plurality of first time steps are obtained by dividing;

[0103] Converting register traces, heap traces, stack traces, and instruction traces generated when executing test cases for source codes of defects to be located in each first time step into vectors to obtain first timing vectors corresponding to each first time step;

[0104] The first time series vectors corresponding to each first time step are arranged in time order to obtain a first time series vector sequence.

[0105] In this embodiment, by converting the register trace, heap trace, stack trace and instruction trace information generated when executing the test case of the source code of the defect to be located in each first time step into vectorized form, the collected trace data can be converted into a timing input form that can be processed by the model, thereby laying a good data foundation for defect location by the defect localization model trained later.

[0106] In the above, one first time step is divided for each instruction executed according to the source code of the defect to be located, and multiple first time steps are obtained by division. It can be that each instruction executed by the source code of the defect to be located (that is, the program) is one time step, that is, each instruction is one time step, so that multiple time steps can be obtained.

[0107] In some implementations, a defect location report is determined based on the probability of each first time step containing a defect and the register trace, the stack trace, the stack trace, and the instruction trace generated when the source code of the defect to be located executes the test case, including:

[0108] Locate each line of code of the source code of the defect to be located according to the register trace, the stack trace, the stack trace and the instruction trace generated when the test case is executed in the source code of the defect to be located in each first time step;

[0109] Each line of code in each first time step is matched with the probability of containing a defect in each first time step, and a defect location report is generated.

[0110] In this embodiment, each line of the source code of the defect to be located is located according to the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located in each first time step executes the test case; each line of code in each first time step is matched with the defect location result corresponding to each time step, and a defect location report is generated. Since the time step refers to the execution of each instruction of the program as a time step, it can be obtained which instruction has a defect, and thus the type of the defect of the line of code can be obtained, making the defect location more accurate.

[0111] To facilitate understanding by those skilled in the art, a set of best embodiments is provided below:

[0112] Existing defect localization techniques, such as program spectrum-based defect localization (SBFL) and mutation-based defect localization (MFBL), usually rely on a single data source in program execution, such as code coverage, test case results, or mutation testing. Although these methods can provide suspicion calculations for code lines, they are difficult to capture the complex multi-dimensional dynamic behavior of programs during operation due to the single source of information. Especially when dealing with complex systems or multi-threaded concurrent environments, these techniques are prone to miss fine-grained defects, resulting in insufficient accuracy in suspicion calculations, which in turn affects the accuracy of defect localization. This single data source analysis method has the following three limitations:

[0113] (1) Focusing only on a single trace: Existing research techniques only focus on the execution of a program in a single trace (i.e., a line of code), lacking the capture and analysis of dynamic behaviors of multiple traces. These traces include register status, heap memory allocation, stack call sequence, and instruction information. Registers include general registers, program counters (PC / IP), stack pointers and base pointers, flag registers, and special registers.

[0114] The reason is: SBFL relies on the code coverage of test cases, while MBFL relies on the behavior of generated variants. Both can only capture the execution trace of a single test case or a single variant. A single execution trace often leads to a simplification of program behavior and fails to capture dynamic changes in multiple dimensions during execution. This means that important information during program runtime (such as registers, memory, stack, and instructions) is not fully utilized, which in turn limits the breadth and depth of defect location. Existing methods can only identify that certain specific lines of code are triggered, but lack in-depth insights into the specific behavior of these lines of code during execution.

[0115] The analysis of SBFL and MBFL is based on the code coverage or variant behavior of the test cases. They can only see the performance of the program under specific input and execution traces. Code coverage or variant behavior can only reflect which parts of the program are executed, and will not analyze the information of other traces. This single data source determines that the existing technology can only analyze a certain execution trace, while ignoring the information of other traces.

[0116] (2) Unable to capture the dynamic behavior of the program: Existing research techniques only analyze the static or single execution trace of the program at the code line level, and cannot capture the dynamic behavior at runtime, such as register status, heap memory allocation and release, stack call sequence, and instruction information executed during program execution. This analysis method ignores important behaviors related to dynamic resource management during program operation.

[0117] The reason is that existing technologies, especially SBFL, rely on the code coverage of test cases, which only reflects which lines of code are triggered when the test cases are executed, but fails to combine the multi-dimensional data of the program runtime for comprehensive analysis, and cannot reveal the specific dynamic state information of the program execution (such as register changes, memory allocation, and instruction execution changes). Therefore, these methods can only reflect the performance of the program at the static code level when locating defects, and cannot capture resource management problems at runtime. This defect limits the ability of existing technologies to locate dynamic defects in complex programs. Compared with traditional analysis methods, the analysis of dynamic behavior can capture more runtime exception patterns.

[0118] SBFL and MBFL technologies lack a comprehensive analysis of the dynamic state of the program at runtime, which leads to the neglect of the execution state of the program in different running trajectories, which limits their performance in complex systems. For example, after the code is executed, whether the memory is correctly released, whether the register value changes abnormally, and whether the instruction execution is normal, these key dynamic behaviors cannot be obtained through code coverage analysis. This leads to the limitations of existing technologies.

[0119] (3) Difficulty in locating multi-thread defects: Existing defect location technologies mainly rely on static code analysis, single-thread execution trace analysis, or dynamic analysis based on test coverage, which makes it difficult to locate multi-thread defects. For example, existing technologies cannot accurately capture the competitive behavior between threads, and lack timing information, making it difficult to detect race conditions; and the dynamic tracking of lock dependencies is insufficient, making it impossible to identify complex lock acquisition sequences and implicit resource waiting chains; and it is impossible to dynamically track thread access to shared resources, making it difficult to locate resource contention problems.

[0120] The reason is that the limitations of existing defect location technology in a multi-threaded environment are mainly due to insufficient tracking of the dynamic behavior of the program at runtime, lack of analysis of time series dependencies, and lack of multi-dimensional information fusion. Concurrency defects such as race conditions, deadlocks, and resource contention in multi-threaded programs often rely on the interaction timing and resource competition timing of multiple threads. Existing technologies are too dependent on a single data source and do not comprehensively analyze multi-dimensional information such as register status, stack operations, and resource access between threads, which makes it difficult for existing technologies to locate multi-threaded defects.

[0121] Existing technologies have difficulty capturing the dynamic behavior of each thread in a multithreaded program at runtime, especially the access to shared resources between threads, changes in register states, stack operations, and instruction execution. This results in the inability to effectively locate key concurrency issues in multithreading (such as race conditions, deadlocks, resource contention, etc.).

[0122] To solve the above-mentioned problems, this embodiment establishes a new complete process framework for software defect location to solve the three core problems existing in the prior art in software defect location, namely, the limitation of focusing only on a single trajectory, the limitation of being unable to capture dynamic behavior, and the limitation of difficulty in locating multi-threaded defects, so as to realize defect location of software.

[0123] Specifically, the software defect location method of this embodiment is divided into two parts: data set generation and defect location model construction. First, an executable software project data set (i.e., software defect location data set) is constructed. The project in the data set is run in QEMU (Quick Emulator), and QEMU and GDB are used to collect the behavior information generated by the project program during operation. The behavior information includes register, heap, stack and instruction information generated by the program when the virtual machine is running, where the registers include general registers, program counters (PC / IP), stack pointers and base pointers, flag registers and special registers. The collected multi-dimensional program runtime information of registers, heaps, stacks and instructions is input into the encoder part of the Transformer model for training and inference. Here, the combination of the encoder part, the fully connected layer and the activation function of the Transformer model is called a defect location model. The input format of the defect location model is sequence data, so it is necessary to preprocess these dynamic data into a time-series vector representation that conforms to the input format of the defect location model. Specifically, the register state, heap memory operation, stack call order and instruction flow information during program runtime will be serialized into an input vector of the time step. The input of each time step (such as time t) is represented as a multi-dimensional vector, covering the dynamic data of registers, heaps, stacks and instructions. The intermediate processing flow mainly retains the time step information by using position encoding, so that the defect localization model can capture the temporal dependency of the input sequence. Through the multi-head self-attention mechanism and feedforward neural network, the input time-series dynamic data is subjected to global dependency analysis and nonlinear transformation to capture potential defects in the program. The output of the defect localization model is the defect location prediction generated based on the input timing data, that is, the suspicion score of the instruction corresponding to each time period. The higher the suspicion score, the more likely the instruction in the time period is to have defects. According to the suspicion score of each moment (i.e. each time step) output by the defect localization model, it is combined with the acquired trajectory information to locate the specific line of code, and finally generate a defect localization report. The report contains whether there is a defect in each line of code. If there is a defect, the defect location and the cause of the defect are given.

[0124] Based on the software defect location model of multiple dynamic program execution traces, this embodiment can capture program runtime information based on existing project codes and test cases, and locate defects in new projects. The technical solution of this embodiment specifically includes the following contents:

[0125] 1. Dataset (i.e., software defect location dataset) generation.

[0126] Compared with the existing software defect location dataset, the defect location method of this embodiment requires the software to be an executable project and the labels are more complex, which cannot be directly generated by the existing dataset. This embodiment collects the source code, test cases, documents, submission history and PR (pull request) of the project based on the open source executable software projects on code hosting platforms such as github and gitee.

[0127] By analyzing the code change history of open source software projects, especially PRs, the code before and after PRs is considered as a change from "defective" to "defect-free". By identifying PRs related to vulnerability fixes, as well as their labels and comments, it is possible to distinguish between defective and defect-free code versions and defective and defect-free code lines. Natural language processing technology is used to identify whether PRs are related to vulnerabilities, and related PRs are clustered into clusters by time windows to determine the number and location of defects. In this way, relevant defect data can be obtained from public code hosting platforms to form an operational software defect location dataset, such as Figure 2 shown.

[0128] 2. Construction of the overall framework for defect location.

[0129] The overall framework of the defect location model constructed in this embodiment is as follows: Figure 3 The framework includes trajectory collection module, information preprocessing module, defect location model building module and defect location report generation module. Figure 3 The solid arrow shows the defect localization model construction phase. First, the software project in the dataset is run in the client, and the test case is input. The program is executed using QEMU and combined with GDB to capture the program's behavior information. Four trace information are obtained, namely the register trace, the heap trace, the stack trace, and the instruction trace. The trace data is then preprocessed to mark the traces with defects and the traces without defects, and the trace information is converted into a timing vector (i.e., a second timing vector sequence set is obtained), where each vector contains the trace information of the program at that moment. After the data processing is completed, the constructed defect localization model is trained using the processed data, and then the model parameters are saved and the defect localization model file is generated (i.e., a trained defect localization model is obtained). The trained defect localization model can be used for subsequent defect location. Figure 3The dotted arrow shows the defect location stage. The vector obtained by preprocessing information (i.e., the first time series vector sequence) is directly input into the trained defect location model to obtain the probability of each time step trajectory containing defects. Combining it with the trajectory information, it can locate the specific line of code and finally generate a defect location report. The report contains whether there is a defect in each line of code. If there is a defect, the defect location and cause are given. The following is a detailed description of each module:

[0130] (1) Trajectory collection.

[0131] This embodiment runs the collected executable software projects on the client, and uses QEMU combined with GDB to capture the specific behavioral characteristics of each line of code of the program when it is running in the system, including capturing registers, heaps, stacks and instruction information. The capture process of the trace is as follows: Figure 4 shown.

[0132] Trajectory data capture: Trajectory data capture refers to obtaining dynamic behavior information related to program operation through monitoring tools during program execution, so as to conduct further analysis and defect location. When modern programs are running, they will generate a large amount of dynamic data related to hardware resources, memory management, function calls, etc. These data can provide important clues to help analyze the execution status of the program and possible defects. In this embodiment, trajectory data capture uses the QEMU virtualization platform and the GDB debugger (i.e., the GNU debugger) to obtain key information when the program is running, including registers, heaps, stacks, and instruction information. Through this data capture method, every important dynamic change during the program's operation can be recorded in detail and associated with specific source code lines, thereby providing sufficient basic data for defect location. The following describes how to capture each trajectory data:

[0133] Register information (i.e., register trace) capture: Registers are hardware components used by the CPU to store temporary data during program execution. The state of the registers directly reflects the operations currently performed by the program, including calculations, memory accesses, and changes in control flow. This embodiment captures the state of the registers in three steps: (1) Start GDB and connect to the debug port of QEMU to capture the running state of the program and the dynamic information of each line of code. (2) Enable line-by-line tracing, execute instructions line by line through the stepi command, and capture the execution of each line of code. (3) Capture register information. Each time the program is executed line by line, the info registers command can be used to view the current state of the registers.

[0134] Heap information (i.e., heap trace) capture: Heap memory is the area where the program dynamically allocates and releases memory, and is usually used to manage data objects during program runtime. Improper management of heap memory may lead to memory leaks or other errors. Therefore, capturing the allocation and release of heap memory is a key step in analyzing the memory management behavior of the program. Specifically: (1) Set breakpoints to monitor memory allocation and release: Set breakpoints on standard memory management functions (such as malloc and free) to monitor the allocation and release of heap memory. When the program calls these functions, GDB will pause the program and display the relevant memory address and size. (2) View the allocated memory address: When the breakpoint is hit, use the print command to view the specific address of the heap memory allocation and record the relevant information. Through the above method, it is possible to continuously capture the dynamic allocation and release information of all heap memory during program execution, helping to locate potential problems in memory management, such as memory leaks.

[0135] Capture of stack information (i.e., stack trace): The stack is used to store function calls, parameters, and local variables, and is the core of the function call chain. By capturing the stack information, you can understand the order of function calls in the program, the recursive depth, and the storage of local variables. Stack information capture is specifically divided into the following two steps: (1) Capture the function call stack: The backtrace command can be used to view the current function call stack, which displays the call chain information when each line of code in the program is executed. This command is executed after each stepi to capture the complete function call stack. (2) Capture stack frame and stack pointer information: View the values ​​of the stack frame pointer (ebp) and stack pointer (esp) through info registers to capture stack frame changes in real time. This information helps to understand the layout of local variables and parameters in the stack each time a function is called.

[0136] Instruction information (i.e. instruction trace) capture: Instruction information is the lowest level of expression when the program is running, which records the specific execution of each step of the operation. By capturing and analyzing the instruction stream of the program, developers can understand the specific behaviors of the program such as control flow, data flow, memory operation, etc. This plays a vital role in defect location. Instruction information capture can use QEMU's "-d" option to capture the instruction stream, and use the "-D" option to save the instruction trace information to a file for subsequent analysis. QEMU will record each executed instruction in a log file, and you can understand the detailed process of program execution by analyzing the log.

[0137] (2) Preprocessing information.

[0138] After obtaining the register trace, heap trace, stack trace, and instruction trace of the program running, the collected trace data needs to be converted into a timing input form that can be processed by the defect localization model. This process is called data serialization and input vectorization. Its purpose is to convert different types of dynamic program behavior information into timing input sequences and represent them as vectors so that the defect localization model can process them.

[0139] Time step division: Divide the program execution into multiple discrete time steps according to time , at each time step Record the status of the program. The time step here refers to the execution of each instruction by the program as a time step. Each time step contains the register status, stack operation, stack call and instruction information of the current time step.

[0140] Input vectorization: Input vectorization refers to converting the data of each time step into a fixed-length vector representation so that the model can process it. The vectorization process converts the original data (such as registers, stacks, and instructions) into a numerical representation that can be used as input for the defect localization model. ,The collected data can be divided into four parts: register information, heap information, stack information and instruction information.,A vector composed of these parts is constructed for each time step.

[0141] ;

[0142] in, Indicates that the program is in time step Runtime information at the moment (including register status, heap, stack and instruction information).

[0143] For example, suppose that at time step , the following information was captured: Contains the values ​​of 8 registers , Involves heap memory operations for the current time step , The current top of the stack . is the instruction for the current time step, such as , which is transformed into a vector by embedding . Therefore, the final input vector is:

[0144] ;

[0145] Serialization: Arrange the data of each time step in chronological order to form a time series:

[0146] ;

[0147] These vectorized data are used as input of the defect localization model.

[0148] (3) Construction of defect location model.

[0149] Transformer consists of an encoder and a decoder, such as Figure 5 As shown. The encoder is mainly responsible for converting the input sequence into a continuous vector representation. The encoder captures the dependencies between different time steps in the input sequence through a multi-head self-attention mechanism, and outputs the context vector of each time step, that is, the feature representation of the program. The decoder is usually used to generate output sequences. Typical applications include machine translation, text generation and other tasks. In these tasks, the model gradually generates outputs related to the input based on the output sequence of the encoder. Since this embodiment mainly needs to extract features from the multi-dimensional dynamic behavior data of the program and provide a defect suspicion score for each time step based on these features, only the encoder part of the Transformer is used. This embodiment uses the Transformer encoder to extract features from the trajectory (i.e. Figure 5 The left part of the image), then passes through the fully connected layer and uses the Sigmoid function to calculate the probability, and finally outputs the suspicion score for each time step.

[0150] The model consists of the following key modules:

[0151] Input embedding layer: First, the input dynamic behavior data is embedded into a high-dimensional space to form an embedding vector. This step is achieved through the embedding layer, which converts the input vector of each time step into an embedded representation of fixed dimension.

[0152] ;

[0153] in, and Represent the trainable weight matrix and bias vector respectively, is the input vector The embedded representation of .

[0154] Position encoding: Since the Transformer model itself cannot perceive the order of the sequence, it is necessary to add position encoding to the input data to ensure that the model can capture the time dependency of the input sequence. The defect localization model in this embodiment uses the encoder part of the Transformer, so position encoding is also required. The position encoding is given by sine and cosine functions of different frequencies:

[0155] ;

[0156] ;

[0157] in, Represents the time step The position code, is the dimension of the input vector. This positional encoding is added to the input embedding vector to indicate the relative order of different time steps.

[0158] Encoder module: The encoder module is the core part of the defect location model. It is composed of 6 encoding layers with the same structure. Each encoding layer is mainly composed of a multi-head self-attention mechanism and a feedforward neural network. The output result of the previous encoding layer is used as the input of the next encoding layer connected to it, that is, the multi-head self-attention mechanism and feedforward neural network are used again to process the input, and 6 encoding layers are used in turn for processing until all 6 encoding layers are processed.

[0159] Multi-head self-attention mechanism: In the Transformer architecture, the multi-head self-attention mechanism is a key component that allows the model to perform multiple self-attention calculations on different "heads" simultaneously, enabling the model to focus on different parts of the input sequence from multiple perspectives, thereby capturing complex dependencies and patterns in the input data. The formula for self-attention is as follows:

[0160] ;

[0161] The formula for multi-head attention is as follows:

[0162] ;

[0163] ;

[0164] in, is the query matrix, representing the input vector at the current time step; is the key matrix, representing the vectors of all time steps in the input sequence; is a matrix of values, representing the information of all time steps in the input sequence; Denote the dimensions of the query and key vectors using Scaling is performed to prevent the inner product result from being too large; Indicates The output of an attention head is represents the number of heads in the multi-head self-attention mechanism, Represents a linear transformation matrix, which is used to linearly combine the outputs of multiple heads.

[0165] Feedforward neural network: The output of each encoder layer passes through a feedforward neural network to further extract nonlinear features. This layer includes two linear transformations and an activation function:

[0166] ;

[0167] in, and is the weight matrix, and is the bias term, Represents the activation function.

[0168] Fully connected layer: In order to map the output feature vector to a real score, a fully connected layer can be connected after the output of the encoder. The function of this fully connected layer is to convert the high-dimensional feature vector into a real value, indicating whether the time step contains a defect score.

[0169] Sigmoid activation function: Finally, the Sigmoid activation function is used to activate each time step The outputs of The interval represents the probability of a defect in this time step, which is recorded as .

[0170] (4) Generate defect location report.

[0171] This module is mainly used to track the code line and generate defect location reports. Specifically:

[0172] Trajectory positioning back to code: After obtaining the probability of the trajectory containing defects at each time step, the trajectory information collected in the trajectory collection module can be used to map to the code line. In this embodiment, QEMU and GDB are combined to parse the instruction address through the captured instruction address (i.e. the value of the PC register) and the debugging symbol table (such as DWARF) to achieve accurate mapping of the behavior trajectory and the source code. This process is a key step to ensure the association between dynamic analysis and static code.

[0173] Usually, the register state, heap memory allocation / release, stack calling sequence and instruction execution are all marked by the instruction address. The instruction address is the value of the PC register corresponding to each trajectory, which can reflect the specific instruction position when the program is executed. For example, suppose the behavior trajectory captured at this time step is "0x4005d0:mov eax,0x1". The meaning of this trajectory is to assign 0x1 to register eax (i.e., accumulator register). This embodiment uses a debugging tool to map the instruction address to the source code line. In order to map the captured instruction address to a specific source code line, with the help of the GDB debugger and the debugging symbol table (such as DWARF), the command "info line*0x4005d0" is used to map the instruction address 0x4005d0 to the source code line. Assuming that the output is "Line45of"source_file.c"", it can be known that the source code mapped to 0x4005d0 is the 45th line of source_file.c. Similarly, all other instruction addresses can be mapped to the source code.

[0174] Defect location report generation: After establishing a connection between the trace information and the source code through the method in the previous step, a defect location report can be generated. It can be obtained whether the code line has a defect and at which time step the trace information has a defect. Since the time step refers to the execution of each instruction of the program as a time step, it can be determined which instruction has a defect, and thus the type of defect can be obtained.

[0175] Compared with the prior art, this embodiment has the following advantages:

[0176] 1. Use QEMU to execute the program and combine with GDB to capture dynamic information: This embodiment uses QEMU as a virtual machine monitoring tool and combines with GDB to capture detailed data when the program is running, including register, heap, stack and instruction information. This method provides more in-depth dynamic information than traditional static code and provides a new solution for software defect location.

[0177] 2. Defect location using multiple dynamic program execution trajectories: This embodiment captures the behavioral trajectory information of registers, heap memory, stack calls, and instruction executions during program execution, obtains the suspicion score for each time step through the defect location model, and finally locates the source code to determine whether the source code has defects. If there are defects, the cause of the defect is given. This embodiment can more comprehensively capture the complex behavioral differences during program execution, especially in dealing with dynamic memory allocation, recursive calls, register state changes, etc. It can improve the accuracy of defect location. The fusion of different trajectory information can help locate a wider range of defects, rather than just being limited to single-dimensional analysis.

[0178] 3. Solve the problem of defect location in a multi-threaded environment: This embodiment can effectively handle defect location in a multi-threaded environment by capturing the behavior trajectories of multiple threads and using the defect location model of this embodiment for modeling. By capturing the behavioral interactions between threads (such as register status, heap memory operations, stack call order, etc.), this embodiment can identify race conditions and resource contention problems and accurately locate defects in the program.

[0179] 4. Dataset source: The dataset of this embodiment collects executable software projects from open source codes, and no existing dataset is used.

[0180] Reference Figure 6 For ease of understanding, this embodiment gives the following examples:

[0181] (1) Construct a dataset.

[0182] Use automated scripts to collect publicly available, executable software projects from Github and Gitee. According to the dataset generation process, extract software defect information from code, test cases, documents, submission history, and PR information, and organize them into a software defect location dataset.

[0183] (2) Trajectory collection.

[0184] Use QEMU to execute the program and combine it with GDB to capture the register trace, stack trace, heap trace and instruction trace when the program code is running.

[0185] (3) Preprocess trajectory information.

[0186] The trajectory data collected in step (2) is converted into a time series input form that can be processed by the defect localization model.

[0187] (4) Defect location model training.

[0188] The multi-dimensional program runtime information of registers, heaps, stacks and instructions collected in step (3) is input into the defect localization model constructed in this embodiment for training and inference. The defect localization model parameters are saved. Finally, a file of the defect localization model is obtained.

[0189] (5) Calculation of the probability that the trajectory contains defects.

[0190] By directly inputting the vector obtained from the preprocessing information (i.e., the first time series vector sequence corresponding to the source code of the defect to be located) into the trained defect localization model, the probability of the trajectory containing a defect at each time step can be obtained.

[0191] (6) Generate defect location report.

[0192] Combine QEMU and GDB to parse instruction addresses through the value of the PC register and the debugging symbol table (such as DWARF) to achieve accurate mapping of behavior traces and source code. Locate specific lines of code and eventually generate a defect location report, which includes whether each line of code has a defect. If there is a defect, the defect location and cause are given.

[0193] Reference Figure 7 The embodiment of the present application also provides a software defect location system based on multiple dynamic program execution trajectories. The system includes a data acquisition unit 100, a trajectory capture unit 200, a vectorization unit 300, a probability acquisition unit 400 and a defect location unit 500, wherein:

[0194] The data acquisition unit 100 is used to acquire the source code of the defect to be located and the test case corresponding to the source code of the defect to be located;

[0195] The trace capture unit 200 is used to capture the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case;

[0196] The vectorization unit 300 is used to vectorize the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case according to the first time step to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is a first time step;

[0197] The probability obtaining unit 400 is used to input the first time series vector sequence into the trained defect location model to obtain the probability of each first time step containing a defect;

[0198] The defect location unit 500 is used to determine a defect location report according to the probability of containing a defect in each first time step and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

[0199] It should be noted that since the software defect localization system based on multiple dynamic program execution trajectories in this embodiment and the above-mentioned software defect localization method based on multiple dynamic program execution trajectories are based on the same inventive concept, the corresponding contents in the method embodiment are also applicable to the system embodiment and will not be described in detail here.

[0200] Reference Figure 8 The embodiment of the present application further provides an electronic device, the electronic device comprising:

[0201] at least one memory;

[0202] at least one processor;

[0203] at least one program;

[0204] The program is stored in the memory, and the processor executes at least one program to implement the software defect location method based on multiple dynamic program execution traces implemented in the present disclosure.

[0205] The electronic device may be any intelligent terminal including a mobile phone, a tablet computer, a personal digital assistant (PDA), a car computer, etc.

[0206] The electronic device according to the embodiment of the present application is described in detail below.

[0207] The processor 1600 may be implemented by a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided by the embodiments of the present disclosure;

[0208] The memory 1700 may be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1700 may store an operating system and other application programs. When the technical solution provided in the embodiments of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1700, and the processor 1600 calls and executes the software defect location method based on multiple dynamic program execution traces of the embodiment of the present disclosure.

[0209] Input / output interface 1800, used to implement information input and output;

[0210] Communication interface 1900, used to realize communication interaction between the device and other devices, which can be realized through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WIFI, Bluetooth, etc.);

[0211] Bus 2000 , which transmits information between various components of the device (e.g., processor 1600 , memory 1700 , input / output interface 1800 , and communication interface 1900 );

[0212] The processor 1600 , the memory 1700 , the input / output interface 1800 , and the communication interface 1900 are connected to each other in communication within the device via the bus 2000 .

[0213] The embodiment of the present disclosure also provides a storage medium, which is a computer-readable storage medium. The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the above-mentioned software defect location method based on multiple dynamic program execution trajectories.

[0214] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0215] The embodiments described in the embodiments of the present disclosure are intended to more clearly illustrate the technical solutions of the embodiments of the present disclosure and do not constitute a limitation on the technical solutions provided by the embodiments of the present disclosure. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present disclosure are also applicable to similar technical problems.

[0216] Those skilled in the art will appreciate that the technical solutions shown in the figures do not limit the embodiments of the present disclosure and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0217] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0218] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0219] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0220] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0221] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0222] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0223] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0224] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable an electronic device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store programs. The above is a detailed description of the embodiments of the present application in conjunction with the accompanying drawings, but the present application is not limited to the above embodiments. Within the scope of knowledge possessed by ordinary technicians in the relevant technical field, various changes can be made without departing from the purpose of the present application.

Claims

1. A software defect location method based on multiple dynamic program execution trajectories, characterized in that: The method comprises: Obtaining source code of a defect to be located and a test case corresponding to the source code of the defect to be located; Capturing register traces, heap traces, stack traces, and instruction traces generated when the source code of the defect to be located executes the test case; According to the first time step, vectorize the register trace, heap trace, stack trace and instruction trace information generated when the source code of the defect to be located executes the test case to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is one of the first time steps; Inputting the first time series vector sequence into a trained defect localization model to obtain the probability of each of the first time steps containing a defect; specifically comprising: The trained defect localization model includes an input embedding layer, a position encoding layer, a plurality of stacked encoding layers, a fully connected layer, and an activation function. The first time series vector sequence is input into the trained defect localization model to obtain a defect localization result corresponding to each time step, including: Inputting the first time series vector sequence into the input embedding layer to obtain an input embedding vector; Inputting the input embedding vector into the position encoding layer for position encoding to obtain a position encoded vector; Inputting the position-encoded vector into a first encoding layer to obtain an output result of the first encoding layer; Using the output result of the first coding layer as the input of the next coding layer connected to the first coding layer, until all coding layers are coded, thereby obtaining a final result after the coding of multiple stacked coding layers is completed; Inputting the final result into the fully connected layer to obtain the result output by the fully connected layer; The activation function is used to normalize the result output by the fully connected layer to obtain the defect location result corresponding to each time step; A defect location report is determined according to the probability of each of the first time steps containing a defect and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

2. The software defect location method based on multiple dynamic program execution trajectories according to claim 1 is characterized in that: The trained defect localization model is obtained in the following way: Acquire a software defect location dataset, wherein the software defect location dataset includes source codes of multiple projects and test cases corresponding to the source codes of each of the projects; Capturing register traces, heap traces, stack traces, and instruction traces generated when the source code of each of the items in the software defect location dataset executes a test case; According to the second time step, the register trace, heap trace, stack trace and instruction trace information generated when the source code of each of the projects executes the test case are vectorized to obtain a second timing vector sequence set, wherein each instruction executed by the source code of each of the projects is one second time step; The constructed defect localization model is trained using the second time series vector sequence set to obtain a trained defect localization model.

3. The software defect location method based on multiple dynamic program execution trajectories according to claim 2 is characterized in that: The step of obtaining a software defect location dataset includes: Collect source code, test cases, documents, submission history, and pull requests of projects on code hosting platforms; Determine the number and location of defects based on the pull request; A software defect location dataset is constructed based on the defect quantity, the defect location, the source code, the test case, the document, and the submission history.

4. The software defect location method based on multiple dynamic program execution trajectories according to claim 1 is characterized in that: The register trace, heap trace, stack trace and instruction trace generated when the source code that captures the defect to be located executes the test case includes: The QEMU virtualization platform and the GDB debugger are used to capture the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

5. The software defect location method based on multiple dynamic program execution trajectories according to claim 1 is characterized in that: According to the first time step, the register trace, the heap trace, the stack trace and the instruction trace information generated when the source code of the defect to be located executes the test case are vectorized to obtain a first timing vector sequence, including: Divide a first time step into each instruction executed according to the source code of the defect to be located, and obtain multiple first time steps; Converting register traces, heap traces, stack traces, and instruction trace information generated when executing a test case on the source code of the defect to be located in each of the first time steps into vectorized form to obtain a first timing vector corresponding to each of the first time steps; The first time series vectors corresponding to each of the first time steps are arranged in time order to obtain a first time series vector sequence.

6. The software defect location method based on multiple dynamic program execution trajectories according to claim 1 is characterized in that: The step of determining a defect location report according to the probability of each of the first time steps containing a defect and the register trace, the stack trace, the stack trace and the instruction trace generated when the source code of the defect to be located executes the test case comprises: Locate each line of code of the source code of the defect to be located according to the register trace, the stack trace, the stack trace and the instruction trace generated when the test case is executed in the source code of the defect to be located in each of the first time steps; Each line of code in each of the first time steps is matched with the probability of containing a defect in each of the first time steps to generate a defect location report.

7. A software defect location system based on multiple dynamic program execution trajectories, characterized in that: The system comprises: A data acquisition unit, used to acquire the source code of the defect to be located and the test case corresponding to the source code of the defect to be located; A trace capture unit, used to capture register traces, heap traces, stack traces and instruction traces generated when the source code of the defect to be located executes the test case; a vectorization unit, configured to vectorize register traces, heap traces, stack traces, and instruction trace information generated when the source code of the defect to be located executes the test case according to the first time step, to obtain a first timing vector sequence, wherein each execution of an instruction of the source code of the defect to be located is one of the first time steps; The probability obtaining unit is used to input the first time series vector sequence into the trained defect location model to obtain the probability of each of the first time steps containing a defect; specifically comprising: The trained defect localization model includes an input embedding layer, a position encoding layer, a plurality of stacked encoding layers, a fully connected layer, and an activation function. The first time series vector sequence is input into the trained defect localization model to obtain a defect localization result corresponding to each time step, including: Inputting the first time series vector sequence into the input embedding layer to obtain an input embedding vector; Inputting the input embedding vector into the position encoding layer for position encoding to obtain a position encoded vector; Inputting the position-encoded vector into a first encoding layer to obtain an output result of the first encoding layer; Using the output result of the first coding layer as the input of the next coding layer connected to the first coding layer, until all coding layers are coded, thereby obtaining a final result after the coding of multiple stacked coding layers is completed; Inputting the final result into the fully connected layer to obtain the result output by the fully connected layer; The activation function is used to normalize the result output by the fully connected layer to obtain the defect location result corresponding to each time step; The defect location unit is used to determine a defect location report according to the probability of each of the first time steps containing defects and the register trace, heap trace, stack trace and instruction trace generated when the source code of the defect to be located executes the test case.

8. An electronic device, characterized in that: It includes at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute the software defect location method based on multiple dynamic program execution trajectories as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the software defect location method based on multiple dynamic program execution trajectories as described in any one of claims 1 to 6.

Images