Fault injection method and device, medium and product

Abstract

The invention discloses a fault injection method and device, a medium and a product, and relates to the technical field of kernel testing. According to the scheme, a plurality of initial fault injection processes are created and executed, and the code block information of the code block corresponding to fault injection is recorded in the execution process of each initial fault injection process, so that the number of hit times and the historical fault rate of the code block are conveniently collected; namely, according to the scheme, the change trend of the code popularity condition and the code fault condition in the fault injection process is considered at the same time, and the strategy of the next round of fault injection is generated based on the change trend, that is, the priority of fault injection of each code block is determined, so that a new round of fault injection process is executed according to the priority of each code block, and the fault injection efficiency is improved. The testing efficiency of the high-failure-rate module can be effectively improved, and therefore potential problems of the system can be revealed more comprehensively.

Description

Technical Field

[0001] The present invention relates to the technical field of kernel testing, and particularly to a fault injection method, device, medium and product. Background Art

[0002] With the increasing complexity of computer systems, the stability and fault tolerance of the operating system kernel are crucial. Especially in scenarios such as cloud computing, storage, and edge computing, abnormal behaviors of kernel modules may lead to serious consequences. To verify the robustness of the kernel under extreme conditions, fault injection technology is widely used to simulate various fault scenarios. By actively injecting controllable fault signals, developers can trigger hidden code paths and evaluate the self-healing ability and fault propagation boundary of the kernel.

[0003] Currently, common kernel fault injection tools are based on system calls. They attempt to discover kernel vulnerabilities through the mutation and serialization of system calls, and use code coverage information to guide the generation and selection of test cases, thereby improving test efficiency and code coverage. However, this fault injection strategy is mainly driven by code coverage, giving priority to testing newly discovered paths and ignoring the impact of historical failure rates. For some modules, although the code coverage may have reached the standard, the historical failure rate of the code is high, and this strategy cannot fully uncover system problems.

[0004] In view of the above, how to solve the problem that the current kernel fault injection strategy overly relies on code coverage, ignores historical failure rates, resulting in insufficient testing of high-failure-rate modules and being unable to fully reveal potential system problems is an urgent problem for those skilled in the art. Summary of the Invention

[0005] The present invention provides a fault injection method, device, medium and product to at least solve the problem that the current kernel fault injection strategy overly relies on code coverage, ignores historical failure rates, resulting in insufficient testing of high-failure-rate modules and being unable to fully reveal potential system problems.

[0006] The present invention provides a fault injection method, including: Create and execute multiple initial fault injection processes, and record the code block information of the corresponding code blocks where faults are injected during the execution of each initial fault injection process; Generate a code block hit linked list according to each code block information; wherein, the code block hit linked list includes at least the hit times of each code block; Obtain the historical failure rate of each code block, and determine the priority of the corresponding code block according to the code block hit linked list and each historical failure rate; Execute new fault injection processes based on each code block and its corresponding priority.

[0007] The present invention also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned fault injection methods when executing the computer program.

[0008] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program implements the steps of any of the above-mentioned fault injection methods when executed by a processor.

[0009] The present invention also provides a computer program product including a computer program, and the computer program implements the steps of any of the above-mentioned fault injection methods when executed by a processor.

[0010] The beneficial effects of the present invention are as follows: by creating and executing multiple initial fault injection processes, and recording the code block information of the corresponding fault injection code blocks during the execution of each initial fault injection process, it is convenient to collect the hit times and historical failure rates of the code blocks; that is to say, this solution simultaneously considers the change trends of code popularity and code failure conditions during the fault injection process, and generates the strategy for the next round of fault injection based on this change trend, that is, determines the priority of fault injection for each code block, so as to execute a new round of fault injection processes according to the priorities of each code block, which can effectively improve the test efficiency of modules with high failure rates, and thus more comprehensively reveal potential problems of the system.

[0011] In addition, the present invention also provides a fault injection device, medium and product with the same effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0013] Figure 1 It is a flowchart of a fault injection method provided by an embodiment of the present invention; Figure 2 It is a schematic diagram of a fault injection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0014] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0015] It should be noted that in the description of the present invention, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present invention are used to distinguish similar objects and not to describe a specific order or sequence.

[0016] In order to enable those skilled in the art of this technology to better understand the solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] Currently, common kernel fault injection tools are based on system calls. By mutating and serializing system calls, they attempt to discover kernel vulnerabilities, and use code coverage information to guide the generation and selection of test cases, thereby improving test efficiency and code coverage. However, this fault injection strategy is mainly driven by code coverage, giving priority to testing newly discovered paths and ignoring the impact of historical failure rates. For some modules, the code coverage may have reached the standard, but the historical failure rate of the code is high, and this strategy cannot fully uncover system problems. Therefore, to solve the above problems, the present invention provides a fault injection method. It should be noted that the method provided by the present invention is applied to the kernel of a computing system, such as the Linux kernel or other types of kernels, and is not limited in this embodiment.

[0018] Figure 1 It is a flowchart of a fault injection method provided by an embodiment of the present invention. As Figure 1 shown, the method includes: S10: Create and execute multiple initial fault injection processes, and record the code block information of the corresponding code blocks for fault injection during the execution of each initial fault injection process.

[0019] Specifically, first create multiple initial fault injection processes, that is, processes for injecting initial test cases into the kernel. When the program starts, execute a preset initial test case library to trigger the basic execution path of the kernel and generate initial code coverage data. It should be noted that in this embodiment, the initial test case library should at least include high-frequency system call combinations, such as file operations, process management, network communication, etc. It should also be noted that in this embodiment, multiple initial fault injection processes can be created simultaneously, and each process executes concurrently with non-interfering resources. The specific creation process of the initial fault injection process in this embodiment is not limited.

[0020] Meanwhile, during the execution of each initial fault injection process, record the code block information of the code block corresponding to the fault injection. It can be understood that a code block refers to a relatively independent code segment with a specific function in the kernel program, without branches entering or exiting. These code blocks can be functions, methods, loops, conditional statements, etc., which perform specific tasks or operations during program execution. In this embodiment, the specific type of the code block is not limited. In addition, the specific content of the code block information in this embodiment is not limited. For example, it may include basic information, function description, starting address, hit count, and resource usage, etc., depending on the specific implementation.

[0021] S11: Generate a code block hit linked list according to each code block information.

[0022] Among them, the code block hit linked list at least includes the hit counts of each code block.

[0023] Furthermore, after obtaining the code block information of each code block, generate a code block hit linked list according to each code block information. It should be noted that the code block hit linked list at least includes the hit counts of each code block. The hit count refers to the number of times the code block is executed in the corresponding process. In this embodiment, the specific content included in the code block hit linked list is not limited. In addition to including the hit counts of the code blocks, it may also include other information of the code blocks.

[0024] S12: Obtain the historical failure rate of each code block, and determine the priority of the corresponding code block according to the code block hit linked list and each historical failure rate.

[0025] S13: Execute a new fault injection process based on each code block and its corresponding priority.

[0026] Subsequently, obtain the historical failure rate of each code block. In this embodiment, the historical failure rate of each code block can be directly obtained from the historical fault library or calculated. In this embodiment, the determination method of the historical failure rate is not limited. Meanwhile, determine the priority of the corresponding code block according to the code block hit linked list and each historical failure rate.

[0027] It is worth noting that the priority of each code block is a reference for the order of the new round of fault injection. Among all the code blocks, the code block with a higher corresponding priority will be injected with faults first in the new round of fault injection. By this method, both the code heat situation and the change trend of the code fault situation during the fault injection process are considered, and a strategy for the next round of fault injection is generated based on this change trend, which can effectively improve the test efficiency of modules with a high failure rate.

[0028] It should be noted that in this embodiment, the specific process of determining the priority of the corresponding code block according to the code block hit list and each historical failure rate is not limited, and at the same time, the specific process of executing a new fault injection process based on each code block and its corresponding priority is not limited, which depends on the specific implementation situation.

[0029] In this embodiment, by creating and executing multiple initial fault injection processes, the code block information of the code block corresponding to the fault injection is recorded during the execution of each initial fault injection process, so as to facilitate the collection of the hit times and historical failure rates of the code block; that is to say, this solution takes into account the change trends of code heat and code failure conditions during the fault injection process, and generates a strategy for the next round of fault injection based on this change trend, that is, determines the priority of fault injection for each code block, so as to execute a new round of fault injection processes according to the priorities of each code block, which can effectively improve the test efficiency of modules with high failure rates, and thus more comprehensively reveal potential problems in the system.

[0030] In order to create and execute multiple initial fault injection processes, based on the above embodiments, in some embodiments, creating and executing multiple initial fault injection processes includes: S101: Create a dedicated control group corresponding to each initial fault injection process based on the control group directory; S102: Set the resource limits of the corresponding initial fault injection process according to each dedicated control group; Among them, the resource limits include at least central processing unit resource limits and memory resource limits; S103: Create a corresponding memory buffer for each initial fault injection process based on a preset kernel coverage measurement tool; S104: Map each memory buffer to the virtual address space of the user state through the memory mapping system call function, and start the code coverage tracking function of the preset kernel coverage measurement tool.

[0031] Specifically, first create a dedicated control group corresponding to each initial fault injection process based on the control group (cgroup) directory, and set the resource limits of the corresponding initial fault injection process according to each dedicated control group. It should be noted that the resource limits include at least central processing unit (CPU) resource limits and memory resource limits; for example, the CPU quota is set by the cpu.max file to limit the computing resource occupancy of the fault injection process; the memory upper limit is set by setting memory.max to a preset value, and when the limit is exceeded, an out-of-memory (OOM) is immediately triggered to terminate the process. Other resource limits may also be included, depending on the specific implementation situation.

[0032] To further enable code coverage tracking, first, open the pre-set kernel coverage measurement tool (such as the KCOV device) mapped under the system and set the tracking mode. Then, notify the kernel to allocate a memory buffer of a specified size through the corresponding command (such as the ioctl command) for storing the coverage data. The kernel will pre-allocate a continuous memory block according to this parameter, and all subsequent coverage data will be written to this area.

[0033] Finally, use the memory mapping system call function (such as mmap) to directly map the memory buffer allocated by the kernel to the virtual address space of the user state, and enable the code coverage tracking function of KCOV through the ioctl command.

[0034] In this way, the complete creation and execution of the initial fault injection process are realized, so as to completely collect and accurately store the code block information.

[0035] Based on the above embodiments, in some embodiments, during the execution of each initial fault injection process, record the code block information of the corresponding fault injection code block, including: S105: Determine the starting address of the fault injection code block corresponding to the initial fault injection process; S106: Store the starting address into the memory buffer corresponding to the initial fault injection process.

[0036] Specifically, during the execution of the initial fault injection process, whenever a code block is executed, record its corresponding starting address (program counter). It can be understood that a code block is a section of sequentially executed code without branches entering or exiting. For example, each direction of a judgment branch is counted as a code block, and each code block corresponds to a unique program counter address. Finally, store the starting address into the memory buffer corresponding to the initial fault injection process.

[0037] In this embodiment, by determining the starting address of the fault injection code block corresponding to the initial fault injection process and storing the starting address into the memory buffer corresponding to the initial fault injection process, the acquisition and storage of the code block information are realized, so as to facilitate the subsequent determination of the hit times of each code block using the starting address.

[0038] Based on the above embodiments, in some embodiments, generate a code block hit linked list according to each code block information, including: S111: Perform hash calculation on the starting addresses in each memory buffer respectively to determine the hit times of each starting address in each memory buffer; S112: Determine the hit times of the code blocks corresponding to each initial fault injection process according to the hit times of each starting address in each memory buffer; S113: Generate a code block hit linked list based on the hit counts of the code blocks corresponding to each initial fault injection process.

[0039] To generate the code block hit linked list, in this embodiment, specifically perform hash calculations on the starting addresses in each memory buffer to determine the hit counts of each starting address in each memory buffer. It should be noted that in this embodiment, neither the hash algorithm nor the number of calculation times used for the hash calculation is limited, and it depends on the specific implementation situation.

[0040] Further, based on the hit counts of each starting address in each memory buffer, determine the hit counts of the code blocks corresponding to each initial fault injection process. Finally, generate a code block hit linked list based on the hit counts of the code blocks corresponding to each initial fault injection process. In this way, the generation of the code block hit linked list is achieved.

[0041] Considering that hash conflicts may cause the code block coverage statistics to be distorted, in order to ensure the accurate generation of the code block hit linked list, in the specific implementation, perform hash calculations on the starting addresses in each memory buffer to determine the hit counts of each starting address in each memory buffer, including: S114: Select the current starting address from the starting addresses in the memory buffer; S115: Determine the first hash value of the current starting address according to the first hash function, and determine the second hash value of the current starting address according to the second hash function; S116: Determine the main slot index according to the first hash value, and determine the target slot corresponding to the current starting address in the locally created hash table according to the main slot index; S117: Determine whether the target slot is empty; if so, go to step S118; if not, go to step S119; S118: Write the current starting address, the hit count corresponding to the current starting address, the first hash value, and the second hash value into the target slot; S119: Obtain the second hash value in the target slot; S120: Determine whether the second hash value in the target slot is the same as the second hash value of the current starting address; if so, go to step S121; if not, go to step S122; S121: Set the hit count in the target slot to be incremented by 1; S122: Determine the starting address corresponding to the target slot, and execute the address conflict handling process according to the starting address corresponding to the target slot; S123: Select a new current starting address from the remaining starting addresses in the memory buffer, and return to step S115 until all starting addresses are traversed, and complete the update of the local hash table.

[0042] In a specific implementation, this solution proposes a method of double - hash orthogonal verification. First, select the current starting address from each starting address in the memory buffer. It can be understood that the current starting address can be any starting address in the memory buffer. Determine the first hash value of the current starting address according to the first hash function, and determine the second hash value of the current starting address according to the second hash function.

[0043] It should be noted that in this embodiment, the specific types of the first hash function and the second hash function are not restricted. For example, SHA - 1 can be used as the first hash function, and the first 16 bits of the 128 - bit output are intercepted as the first hash value; the second hash function selects the optimized variant of CRC32, and a 16 - bit check code is generated through the polynomial 0xEDB88320 to obtain the second hash value.

[0044] Subsequently, determine the main slot index according to the first hash value, and determine the target slot corresponding to the current starting address in the pre - created local hash table. It should be noted that the local hash table is a linked list that is pre - created and corresponding to the memory buffer and is used to store the hit times of each starting address. When the local hash table is created for the first time, the local hash table is empty; when the local hash table is not created for the first time, the local hash table contains multiple slots, and each slot contains the corresponding starting address, the hit times corresponding to the starting address, the first hash value, and the second hash value.

[0045] Further, determine whether the target slot corresponding to the current starting address in the local hash table is empty. If it is confirmed that the target slot is empty, it is considered that the hit times of the current starting address are recorded for the first time, and specifically, write the current starting address, the hit times corresponding to the current starting address (1 time), the first hash value, and the second hash value into the target slot. If it is confirmed that the target slot is not empty, it is necessary to obtain the second hash value already stored in the target slot, and determine whether the second hash value in the target slot is the same as the second hash value of the current starting address, so as to determine whether there is a conflict between the current starting address and the starting address already existing in the target slot.

[0046] If it is confirmed that the second hash value in the target slot is the same as the second hash value of the current starting address, it is considered that the current starting address does not conflict with the starting address already existing in the target slot, and the two are the same, and the hit times in the target slot can be set to increase by 1. If it is confirmed that the second hash value in the target slot is not the same as the second hash value of the current starting address, it is considered that the current starting address does not conflict with the starting address already existing in the target slot, and the two are different. At this time, it is necessary to determine the starting address corresponding to the target slot, and execute the address conflict handling process according to the starting address corresponding to the target slot. It should be noted that in this embodiment, the specific process of the address conflict handling process is not restricted and depends on the specific implementation situation.

[0047] The storage of the hit count for the current starting address is completed above. It is also necessary to store the hit counts for the remaining starting addresses in the memory buffer. Specifically, a new current starting address is selected from the remaining starting addresses in the memory buffer, and the process returns to the step of determining the first hash value of the current starting address according to the first hash function and determining the second hash value of the current starting address according to the second hash function until all starting addresses are traversed, completing the update of the local hash table.

[0048] To implement address conflict handling, based on the above embodiments, this solution also provides a mechanism for managing the overflow linked list. Specifically, in some embodiments, an address conflict handling process is performed according to the starting address corresponding to the target slot, including: S124: Determine whether there is a linked list node in the pre-created local overflow linked list that corresponds to the starting address corresponding to the target slot; if not, proceed to step S125; if so, proceed to step S128; S125: Create a target linked list node in the local overflow linked list; S126: Write the starting address in the target slot, the hit count corresponding to the starting address, the first hash value, and the second hash value into the target linked list node; S127: Clear the target slot and write the current starting address, the hit count corresponding to the current starting address, the first hash value, and the second hash value into the target slot; S128: Increment the hit count in the corresponding linked list node by 1; Among them, after all starting addresses in the memory buffer are traversed, the update of the local overflow linked list is completed.

[0049] Specifically, when it is confirmed that the second hash value in the target slot is different from the second hash value of the current starting address, first determine whether there is a linked list node in the pre-created local overflow linked list that corresponds to the starting address corresponding to the target slot. It can be understood that the local overflow linked list is a pre-created linked list corresponding to the memory buffer and is used to store the hit counts of conflicting starting addresses. When the local overflow linked list is created for the first time, the local overflow linked list is empty; when the local overflow linked list is not created for the first time, the local overflow linked list contains multiple linked list nodes, and each linked list node contains the corresponding starting address, the hit count corresponding to the starting address, the first hash value, and the second hash value.

[0050] If it is confirmed that there is no linked list node corresponding to the starting address corresponding to the target slot, it is confirmed that the starting address corresponding to the target slot has not had an address conflict before. It is necessary to create a target linked list node in the local overflow linked list, and write the starting address, the hit count corresponding to the starting address, the first hash value, and the second hash value in the target slot into the target linked list node. Subsequently, clear the target slot, and write the current starting address (i.e., the address that conflicts with the starting address in the target slot), the hit count corresponding to the current starting address, the first hash value, and the second hash value into the target slot, thereby achieving the overflow of the conflict address.

[0051] If it is confirmed that there is a linked list node corresponding to the starting address corresponding to the target slot, it is confirmed that the starting address corresponding to the target slot has had an address conflict before, and it is only necessary to increment the hit count in the corresponding linked list node by 1. It can be understood that after all the starting addresses in the memory buffer are traversed, the local overflow linked list is updated. In other words, the local hash table and the local overflow linked list corresponding to the memory buffer are updated simultaneously.

[0052] In summary, through the method of double-hash orthogonal verification and overflow linked list management, the statistical distortion of the code block coverage rate caused by hash conflicts is effectively avoided.

[0053] In the above embodiment, the local hash table and the local overflow linked list of a memory buffer are updated. In order to generate a global code block hit linked list, based on the above embodiment, in some embodiments, generating a code block hit linked list according to the hit counts of the code blocks corresponding to each initial fault injection process includes: S131: Obtain the local hash table and the local overflow linked list corresponding to each memory buffer; S132: Merge the local hash tables to generate a global hash table; S133: Merge the local overflow linked lists to generate a global overflow linked list.

[0054] Specifically, after determining the local hash table and the local overflow linked list corresponding to each memory buffer, perform global merging to count the hit counts of each hash slot (starting address). When the fault injection thread ends, obtain the local hash table and the local overflow linked list corresponding to each memory buffer, merge the local hash tables to generate a global hash table; merge the local overflow linked lists to generate a global overflow linked list. It can be understood that the global hash table and the global overflow linked list together constitute the code block hit linked list.

[0055] It should be noted that when merging the local hash tables, competition may occur in updating the hit counts for the same hash slot. Therefore, atomic operations are required for the merging of the global hash table. It should also be noted that the merging of the global hash table is similar to the merging steps of the local hash tables. When the main hash slot is hit for the first time, if the target slot is empty, the initial hit count value (1 time) is written. If the slot is already occupied, the conflict address is migrated to the global overflow linked list, and then the counter of the main hash slot is reset to 0 as the start of the new address count. Since its specific process is the same as the update process of the local hash table and the local overflow linked list in the above embodiments, this embodiment will not elaborate on it further.

[0056] Based on the above embodiments, in some embodiments, determining the priority of a corresponding code block according to the code block hit linked list and each historical failure rate includes: S141: Determine the code blocks corresponding to a hit count of 1 according to the code block hit linked list; S142: Store the data structures of the code blocks corresponding to a hit count of 1 in the first hit linked list; S143: Determine the code blocks corresponding to a hit count not equal to 1 according to the code block hit linked list; S144: Store the data structures of the code blocks corresponding to a hit count not equal to 1 in the hot code block linked list; S145: Determine the hot zone weight values of the code blocks in the hot code block linked list; S146: Determine the priorities of the code blocks in the hot code block linked list according to the hot zone weight values; Among them, the priorities of the code blocks in the first hit linked list are all higher than the priorities of the code blocks in the hot code block linked list; In order to determine the priorities of the code blocks, in this embodiment, the code blocks corresponding to a hit count of 1 are specifically determined according to the code block hit linked list, that is, the code blocks with a hit count of 1 are obtained from the global hash table and the global overflow linked list. Subsequently, the data structures of the code blocks corresponding to a hit count of 1 are stored in the first hit linked list.

[0057] Further, the code blocks corresponding to a hit count not equal to 1 are determined according to the code block hit linked list, that is, the code blocks with a hit count not equal to 1 are obtained from the global hash table and the global overflow linked list. Subsequently, the data structures of the code blocks corresponding to a hit count not equal to 1 are stored in the hot code block linked list.

[0058] It should be noted that the priority of each code block in the first hit linked list is higher than that of each code block in the hot code block linked list. Therefore, when executing a new fault injection process based on each code block and its corresponding priority, the new fault injection process is executed in descending order according to the priority of each code block in the first hit linked list and the hot code block linked list. That is to say, each code block in the first hit linked list injects faults before each code block in the hot code block linked list to ensure the rapid verification of the new path. It should also be noted that the priorities of each code block in the first hit linked list are the same.

[0059] In order to further determine the priority of each code block in the hot code block linked list, it is necessary to determine the hot area weight value of each code block in the hot code block linked list in the specific implementation, and determine the priority of each code block in the hot code block linked list according to each hot area weight value. It should be noted that the priorities of each code block in the hot code block linked list are different and there is a sequence. In this embodiment, the specific process of determining the hot area weight value of each code block in the hot code block linked list and determining the priority of each code block in the hot code block linked list according to each hot area weight value is not limited and depends on the specific implementation situation.

[0060] In this embodiment, the priority of each code block is initially divided according to whether each code block is a first hit in the initial fault injection process, which improves the efficiency of priority division.

[0061] In order to determine the hot area weight value of each code block in the hot code block linked list, in this embodiment, a code hot area weight model is specifically constructed based on the code heat value, historical failure rate, and system pressure coefficient, so as to dynamically calculate the hot area weight. Specifically, on the basis of the above embodiment, in some embodiments, determining the hot area weight value of each code block in the hot code block linked list includes: S147: Obtain the hit times and the maximum hit times of each code block in the hot code block linked list according to the code block hit linked list; S148: Determine the code heat value of each code block according to the hit times and the maximum hit times of each code block in the hot code block linked list; S149: Obtain the current multiple system performance parameters and determine the current system pressure value according to each system performance parameter; S150: Perform weighted summation according to the historical failure rate, code heat value, and current system pressure value of each code block in the hot code block linked list to determine the hot area weight value of the corresponding code block.

[0062] First, obtain the hit counts and the maximum hit count of each code block in the hot code block linked list according to the code block hit linked list. It should be noted that the maximum hit count is the maximum hit count of all code blocks in the system. Further, determine the code heat value of each code block based on the hit count and the maximum hit count of each code block in the hot code block linked list; the higher the code heat value, the greater the contribution of the hot area weight value.

[0063] Subsequently, obtain the current multiple system performance parameters, and determine the current system pressure value according to each system performance parameter. The greater the current system pressure value, the fewer available resources in the system, and the smaller the contribution of the hot area weight value. It should be noted that in this embodiment, the calculation method of the current system pressure value is not limited.

[0064] Finally, perform a weighted sum according to the historical failure rate, code heat value, and current system pressure value of each code block in the hot code block linked list to determine the hot area weight value of the corresponding code block. It can be understood that the more historical failure times, the greater the contribution of the hot area weight value, reflecting the stability risk of the function. The specific formula for the hot area weight value is as follows: ; Where, is the hot area weight value, is the hit count of code block i, is the maximum hit count, is the code heat value of the code block, is the historical failure trigger count of code block i, is the total failure trigger count of all code blocks in the system, is the historical failure rate of code block i, is the current moment, is the current system pressure value, are all weight coefficients.

[0065] It should also be noted that is used to control the weight of the historical failure rate, The larger it is, the more the system depends on long-term failure statistics, which is suitable for scenarios with high stability requirements. The value range is usually 0.3 - 0.5. is used to control the weight of the real-time health status, The larger it is, the more the system focuses on current performance metrics (such as CPU, latency), and its value is usually 0.2 - 0.4. For example, in high-stability demand scenarios such as financial scenarios, historical repeated failures should be avoided as much as possible. At this time, should be increased (such as 0.4 - 0.6) to strengthen the impact of historical failures, and key monitoring should be carried out on the payment signature verification module that has made mistakes. At the same time, should be decreased (0.3 → 0.2) to reduce the sensitivity to real-time fluctuations and avoid mis-fusing the core trading link.

[0066] In this embodiment, a code hot area weight model is constructed based on the code heat value, historical failure rate, and system pressure coefficient, so as to dynamically calculate the hot area weight, which is convenient for dynamically adjusting the subsequent fault injection strategy.

[0067] Based on the above embodiment, in some embodiments, multiple current system performance parameters are obtained, and the current system pressure value is determined according to each system performance parameter, including: S151: Collect the time ratios of the central processing unit (CPU) in each state according to a first preset period; wherein, the states include at least the user state, kernel state, and idle state; S152: Determine the instantaneous CPU utilization rate according to the difference calculation method and each time ratio; S153: Collect the total memory size, current free memory size, buffer memory size, and cache memory size of the memory according to a second preset period; S154: Determine the used memory size according to the total memory size, current free memory size, buffer memory size, and cache memory size; S155: Obtain the average total time consumption of input / output requests, and obtain the system pressure value at the previous moment; S156: Determine the current system pressure value according to the instantaneous CPU utilization rate, used memory size, total memory size, average total time consumption, and system pressure value at the previous moment.

[0068] In order to determine the current system pressure value, in this embodiment, the time ratios of the CPU in each state are specifically collected according to a first preset period, for example, by parsing the interfaces exposed by the kernel (such as / proc / stat). It should be noted that the states include at least the user state, kernel state, and idle state; at the same time, the size of the first preset period is not limited in this embodiment, for example, it can be 100 ms. Subsequently, the instantaneous CPU utilization rate is determined according to the difference calculation method and each time ratio. The specific calculation is based on the difference between two adjacent data collected in the first preset period to obtain the instantaneous CPU utilization rate. The formula is as follows: ; Wherein, is the instantaneous CPU utilization rate, is the difference between two adjacent CPU times consumed by user-state processes, is the difference between two adjacent CPU times consumed by kernel-state processes, is the difference between two adjacent CPU completely idle times, is the difference between two adjacent CPU idle times with waiting for I / O completion.

[0069] Further, collect the total memory size, the current free memory size, the buffer memory size, and the cache memory size of the memory according to the second preset period, for example, by parsing the interfaces exposed by the kernel (such as / proc / meminfo). It should be noted that the size of the second preset period is not limited in this embodiment. Determine the used memory size according to the total memory size, the current free memory size, the buffer memory size, and the cache memory size. The specific formula is as follows: ; Wherein, is the used memory size, is the total memory size, is the current free memory size, is the buffer memory size, is the cache memory size.

[0070] Subsequently, obtain the average total time consumption of the input / output (IO) requests, and obtain the system pressure value at the previous moment. For example, the average total time consumption of the IO requests under the system can be obtained by using user-space IO tools or by embedding probes in the kernel .

[0071] Finally, determine the current system pressure value according to the instantaneous central processing unit utilization rate, the used memory size, the total memory size, the average total time consumption, and the system pressure value at the previous moment. The specific formula is as follows: ; Wherein, is the current system pressure value, is the smoothing factor, which is used to control the influence degree of the historical pressure value on the current pressure value (the value range is 0 to 1), is the system pressure value at the previous moment, is the threshold value of the IO delay, which is used to normalize the IO delay.

[0072] It should be noted that the above formula for calculating the current system pressure value is based on the exponential weighted moving average method, which integrates multiple system core indicators and combines the historical smoothing factor to smooth the historical pressure data and prevent the influence of short-term fluctuations (such as the instantaneous spike of the CPU pressure) on the pressure value, The value should be related to the specific scenario. For example, in a stability system where the pressure is relatively gentle, the value can be taken between 0.7 and 0.9. For real-time metrics, the formula fuses the key resource metrics of the system through normalization and weighted calculation. The CPU utilization directly determines the saturation of computing resources, affecting the request throughput and response latency, with the highest weight (60%). Memory pressure is usually caused by memory leaks, with a slower reaction speed but serious consequences, and the weight is the second highest (30%), which can effectively capture the progressive risks of the system. The impact of I / O latency usually exists in a certain specific service (such as database query), and the current software system usually reduces its impact through means such as caching, giving it a weight of 10%. In addition, the formula adopts the normalization principle to enable weighted calculation of various system metrics within the same range. The CPU utilization is converted to the range of 0-1, and the memory is normalized to map it to the 0-1 range. Since the weight of IO is low, to avoid undetected extreme abnormal problems in the system, piecewise normalization is adopted to amplify the impact of delays seriously exceeding the threshold, ensuring the discovery of potential serious I / O blocking risks. The I / O latency threshold can be defined according to the actual hardware environment.

[0073] In summary, in this embodiment, by collecting multi-dimensional resource metrics under the real-time acquisition system and constructing a system pressure coefficient model based on the exponentially weighted moving average method, the real-time and accurate calculation of the system pressure value is achieved.

[0074] In order to determine the priorities of each code block in the hot code block linked list, this solution specifically combines the greedy algorithm and the weighted round-robin method based on the hot code block to generate a fault injection strategy. Specifically, on the basis of the above embodiment, in some embodiments, determining the priorities of each code block in the hot code block linked list according to the weight values of each hot area includes: S161: Sort the code blocks in the hot code block linked list in descending order according to the weight values of each hot area to generate a hot area injection queue; S162: Split the hot area injection queue into a first hot area injection sub-queue and a second hot area injection sub-queue; S163: Sort the code blocks in the first hot area injection sub-queue in descending order according to the corresponding hot area weight values to determine the priorities of the code blocks in the first hot area injection sub-queue; S164: Determine the priorities of the code blocks in the second hot area injection sub-queue according to the weighted random algorithm and the hot area weight values of the code blocks in the second hot area injection sub-queue; Among them, the hot area weight values of the code blocks in the first hot area injection sub-queue are all higher than the hot area weight values of the code blocks in the second hot area injection sub-queue; the priorities of the code blocks in the first hot area injection sub-queue are all higher than the priorities of the code blocks in the second hot area injection sub-queue.

[0075] Specifically, each code block in the hot-spot code block linked list is sorted in descending order according to the weight value of each hot zone to generate a hot zone injection queue. For example, the generated hot zone injection queue contains the Top100 code blocks, and each code block is sorted in descending order according to the hot zone weight value. Subsequently, the hot zone injection queue is split into a first hot zone injection sub-queue and a second hot zone injection sub-queue.

[0076] It should be noted that in this embodiment, there is no limitation on the specific splitting of the hot zone injection queue, but it is necessary to ensure that the hot zone weight values of the code blocks in the first hot zone injection sub-queue are all higher than those of the code blocks in the second hot zone injection sub-queue. For example, the hot zone injection queue To-100 can be split into a first hot zone injection sub-queue with a high priority segment (such as Top20) and a second hot zone injection sub-queue with a low priority segment (such as Top21-Top100).

[0077] Subsequently, the greedy algorithm is used to quickly process the hot zone targets with high priority. Specifically, each code block in the first hot zone injection sub-queue (such as Top20) is sorted in descending order according to the corresponding hot zone weight value to determine the priority of each code block in the first hot zone injection sub-queue, and each time the code block with the largest hot zone weight in the queue is directly selected for injection.

[0078] For the second hot zone injection sub-queue with a low priority segment (such as Top21-Top100), the priority of each code block in the second hot zone injection sub-queue needs to be determined according to the weighted random algorithm and the hot zone weight value of each code block in the second hot zone injection sub-queue. It should be noted that the priority of each code block in the first hot zone injection sub-queue is higher than that of each code block in the second hot zone injection sub-queue. The following specifically describes the determination process of the priority of each code block in the second hot zone injection sub-queue: Specifically, according to the weighted random algorithm and the hot zone weight value of each code block in the second hot zone injection sub-queue, determining the priority of each code block in the second hot zone injection sub-queue includes: S165: Determine the probability distribution of each code block in the second hot zone injection sub-queue according to the hot zone weight value of each code block in the second hot zone injection sub-queue; S166: Generate a cumulative probability table according to the probability distribution of each code block in the second hot zone injection sub-queue; S167: Generate a random number and map the random number to the target interval; S168: Locate the smallest index that meets the preset conditions according to the random number, the cumulative probability table, and the binary search method; S169: Determine the corresponding code block in the second hot zone injection sub-queue according to the smallest index and add it to the polling algorithm queue; return to step S167 until all the code blocks in the second hot zone injection sub-queue are added to the polling algorithm queue.

[0079] First, according to the hotness weight values of each code block in the second hot area injection sub-queue (for example, the hot areas of Top21 - Top100, denoted as the set S = {s21, s22,..., s100}), determine the probability distribution of each code block in the second hot area injection sub-queue. Taking the second hot area injection sub-queue as Top21 - Top100 as an example, the probability distribution formula is as follows: ; where, is the probability value of code block i in the second hot area injection sub-queue (Top21 - Top100), .

[0080] Subsequently, generate a cumulative probability table according to the probability distribution of each code block in the second hot area injection sub-queue: ; where, is the cumulative probability table. It can be understood that .

[0081] Furthermore, generate a uniformly distributed random number within the range and map the random number to the target interval . Locate the smallest index that meets the preset conditions according to the random number, the cumulative probability table, and the binary search method. Specifically, use binary search in the cumulative probability table to locate the smallest index that satisfies , determine the corresponding code block in the second hot area injection sub-queue according to the smallest index , and add it to the polling algorithm queue; return to step S167 until all code blocks in the second hot area injection sub-queue are added to the polling algorithm queue. It can be understood that each code block in the polling algorithm queue needs to be polled for injection during fault injection.

[0082] In summary, based on the hot code blocks, combined with the greedy algorithm and the weighted polling method, a fault injection strategy generation is realized. The priority of each code block in the first-hit linked list is higher than that of each code block in the first hot area injection sub-queue, and the priority of each code block in the first hot area injection sub-queue is higher than that of each code block in the second hot area injection sub-queue. Inject faults into the code blocks in the first-hit linked list, the first hot area injection sub-queue, and the second hot area injection sub-queue in sequence, which can effectively shorten the test cycle of the critical path. The weighted polling probability allows the system to explore the medium and low weight areas (such as the edge logic that is not fully covered), preventing potential weak points from being missed in testing.

[0083] To enable those skilled in the art to better understand the fault dynamic injection process provided by this solution, based on the content of the above embodiments, the specific process of executing a new fault injection process based on each code block and its corresponding priority will be described in detail as follows: According to the above three-level priority queue, namely the first-hit linked list, the first hot area injection sub-queue (i.e., the greedy algorithm queue), and the second hot area injection sub-queue (i.e., the weighted round-robin queue), the system dynamically selects code blocks as fault injection points in the order of priority and generates a fault injection mode. The specific steps are as follows: First, starting from the starting address of the code block, read the machine code in the kernel memory byte by byte until the next branch instruction (such as jmp, ret), and then disassemble the machine code into assembly instructions, and identify its internal key nodes (such as conditional branches, loop exits, exception handling entries) through disassembly.

[0084] The system's scheduling policy is: prioritize tasks in the first-hit linked list, and then process tasks in the first hot area injection sub-queue and the second hot area injection sub-queue in sequence; when the system pressure coefficient P(t) exceeds the threshold (such as P(t)>0.8), suspend low-priority injection and only retain the highest-priority tasks, that is, stop processing tasks in the first hot area injection sub-queue and the second hot area injection sub-queue, and only inject code blocks in the first-hit linked list to avoid resource overload.

[0085] Furthermore, to achieve precise fault injection, first perform dynamic mounting of kernel probes, specifically receive the parameters passed by the policy control layer, and use Kprobe to register a probe at the starting address of the code block. Subsequently, perform dynamic configuration of fault types. Specifically, in the Kprobe callback function, the key nodes identified by the probe match the predefined fault templates, triggering the following error types: (1) Return value tampering: Force the function to return an error code (such as using ENOMEM to simulate memory shortage).

[0086] (2) Parameter pollution: Modify the input parameters (such as setting the file handle pointer to NULL to trigger a null pointer exception).

[0087] (3) Execution flow hijacking: Skip the original function logic and jump to the error handling branch.

[0088] Finally, capture the code coverage rate during the fault injection test in real time, perform code heat value statistics, and feedback the code heat value data to facilitate the update of the code block hit linked list.

[0089] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0090] Figure 2 Schematic diagram of a fault injection device provided by an embodiment of the present invention. As Figure 2 shown, the device includes: The first execution module 10 is used to create and execute a plurality of initial fault injection processes, and record the code block information of the corresponding code blocks injected with faults during the execution of each initial fault injection process; The generation module 11 is used to generate a code block hit linked list according to each code block information; wherein, the code block hit linked list at least includes the hit times of each code block; The determination module 12 is used to obtain the historical failure rate of each code block, and determine the priority of the corresponding code block according to the code block hit linked list and each historical failure rate; The second execution module 13 is used to execute new fault injection processes based on each code block and its corresponding priority.

[0091] In some embodiments, the determination module 12 includes: The first determination sub-module is used to determine the code blocks corresponding to the hit times of 1 according to the code block hit linked list; The first storage sub-module is used to store the data structures of each code block corresponding to the hit times of 1 into the first hit linked list; The second determination sub-module is used to determine the code blocks corresponding to the hit times not equal to 1 according to the code block hit linked list; The second storage module is used to store the data structures of each code block corresponding to the hit times not equal to 1 into the hot code block linked list; The third determination sub-module is used to determine the hot area weight values of each code block in the hot code block linked list; The fourth determination sub-module is used to determine the priority of each code block in the hot code block linked list according to each hot area weight value; Among them, the priority of each code block in the first hit linked list is higher than the priority of each code block in the hot code block linked list; Correspondingly, the second execution module 13 includes: The fault injection sub-module is used to execute new fault injection processes in descending order according to the priorities of each code block in the first hit linked list and the hot code block linked list.

[0092] In some embodiments, the third determination sub-module includes: The first acquisition sub-module is used to obtain the hit times and the maximum hit times of each code block in the hot code block linked list according to the code block hit linked list; The fifth determination sub-module is used to determine the code heat value of each code block according to the hit times and the maximum hit times of each code block in the hot code block linked list; The second acquisition module is used to acquire current multiple system performance parameters and determine the current system pressure value according to each system performance parameter; The weighted summation sub-module is used to perform weighted summation according to the historical failure rate, code heat value and current system pressure value of each code block in the hot code block linked list to determine the hot area weight value of the corresponding code block.

[0093] In some embodiments, the second acquisition module includes: The first collection sub-module is used to collect the time proportion of the central processing unit in each state according to the first preset period; wherein, the states at least include the user state, the kernel state and the idle state; The sixth determination sub-module is used to determine the instantaneous central processing unit utilization rate according to the difference calculation method and each time proportion; The second collection sub-module is used to collect the total memory size, current free memory size, buffer memory size and cache memory size of the memory according to the second preset period; The seventh determination sub-module is used to determine the used memory size according to the total memory size, current free memory size, buffer memory size and cache memory size; The third acquisition sub-module is used to acquire the average total time consumption of the input / output request and acquire the system pressure value at the previous moment; The eighth determination sub-module is used to determine the current system pressure value according to the instantaneous central processing unit utilization rate, used memory size, total memory size, average total time consumption and system pressure value at the previous moment.

[0094] In some embodiments, the fourth determination sub-module includes: The hot area injection queue generation sub-module is used to sort each code block in the hot code block linked list in descending order according to each hot area weight value to generate a hot area injection queue; The hot area injection queue splitting sub-module is used to split the hot area injection queue into a first hot area injection sub-queue and a second hot area injection sub-queue; The first priority determination sub-module is used to sort each code block in the first hot area injection sub-queue in descending order according to the corresponding hot area weight value to determine the priority of each code block in the first hot area injection sub-queue; [[ID=3l]] The second priority determination sub-module is used to determine the priority of each code block in the second hot area injection sub-queue according to the weighted random algorithm and the hot area weight value of each code block in the second hot area injection sub-queue; Among them, the hot area weight values of the code blocks in the first hot area injection sub-queue are all higher than those of the code blocks in the second hot area injection sub-queue; the priorities of the code blocks in the first hot area injection sub-queue are all higher than those of the code blocks in the second hot area injection sub-queue.

[0095] In some embodiments, the second priority determination sub-module includes: A probability distribution determination sub-module, configured to determine the probability distribution of each code block in the second hot area injection sub-queue according to the hot area weight value of each code block in the second hot area injection sub-queue; A cumulative probability table generation sub-module, configured to generate a cumulative probability table according to the probability distribution of each code block in the second hot area injection sub-queue; A mapping sub-module, configured to generate a random number and map the random number to a target interval; A positioning sub-module, configured to locate the smallest index that meets the preset condition according to the random number, the cumulative probability table, and the binary search method; A retrieval sub-module, configured to determine the corresponding code block in the second hot area injection sub-queue according to the smallest index and add it to the polling algorithm queue; trigger the mapping sub-module until all the code blocks in the second hot area injection sub-queue are added to the polling algorithm queue.

[0096] In some embodiments, the first execution module 10 includes: An exclusive control group creation sub-module, configured to create an exclusive control group corresponding to each initial fault injection process based on the control group directory; A resource limitation sub-module, configured to set resource limitations for the corresponding initial fault injection processes according to each exclusive control group; where the resource limitations include at least central processing unit resource limitations and memory resource limitations; A memory buffer creation sub-module, configured to create a corresponding memory buffer for each initial fault injection process based on a preset kernel coverage measurement tool; A code coverage tracking sub-module, configured to map each memory buffer to the virtual address space of the user state through the memory mapping system call function, and start the code coverage tracking function of the preset kernel coverage measurement tool.

[0097] In some embodiments, the first execution module 10 includes: A starting address determination sub-module, configured to determine the starting address of the code block for fault injection corresponding to the initial fault injection process; A starting address storage sub-module, configured to store the starting address in the memory buffer corresponding to the initial fault injection process.

[0098] In some embodiments, the generation module 11 includes: The starting address hit count determination sub-module is used to perform hash calculations on the starting addresses in each memory buffer respectively to determine the hit counts of each starting address in each memory buffer; The code block hit count determination sub-module is used to determine the hit counts of the code blocks corresponding to each initial fault injection process according to the hit counts of each starting address in each memory buffer; The code block hit linked list generation sub-module is used to generate a code block hit linked list according to the hit counts of the code blocks corresponding to each initial fault injection process.

[0099] In some embodiments, the starting address hit count determination sub-module includes: The current starting address selection sub-module is used to select the current starting address from the starting addresses in the memory buffer; The hash value calculation sub-module is used to determine the first hash value of the current starting address according to the first hash function and determine the second hash value of the current starting address according to the second hash function; The target slot determination sub-module is used to determine the main slot index according to the first hash value and determine the target slot corresponding to the current starting address in the pre-created local hash table according to the main slot index; The first judgment module is used to judge whether the target slot is empty; if it is confirmed that the target slot is empty, the first writing module is triggered; if it is confirmed that the target slot is not empty, the second hash value obtaining module is triggered; The first writing module is used to write the current starting address, the hit count corresponding to the current starting address, the first hash value and the second hash value into the target slot; The second hash value obtaining module is used to obtain the second hash value in the target slot; The second judgment module is used to judge whether the second hash value in the target slot is the same as the second hash value of the current starting address; if it is confirmed that the second hash value in the target slot is the same as the second hash value of the current starting address, the setting module is triggered; if it is confirmed that the second hash value in the target slot is not the same as the second hash value of the current starting address, the address conflict handling module is triggered; The setting module is used to set the hit count in the target slot to be incremented by 1; The address conflict handling module is used to determine the starting address corresponding to the target slot and execute the address conflict handling process according to the starting address corresponding to the target slot; The new current starting address selection sub-module selects a new current starting address from the remaining starting addresses in the memory buffer and triggers the hash value calculation sub-module until all starting addresses are traversed to complete the update of the local hash table.

[0100] In some embodiments, the address conflict handling module includes: A third judgment module, configured to determine whether there is a linked list node corresponding to the starting address corresponding to the target slot in a pre-created local overflow linked list; if it is confirmed that there is no linked list node corresponding to the starting address corresponding to the target slot, trigger the target linked list node creation sub-module; if it is confirmed that there is a linked list node corresponding to the starting address corresponding to the target slot, trigger the accumulation module; The target linked list node creation sub-module is configured to create a target linked list node in the local overflow linked list; A second writing module, configured to write the starting address, the hit count corresponding to the starting address, the first hash value, and the second hash value in the target slot into the target linked list node; A third writing module, configured to clear the target slot and write the current starting address, the hit count corresponding to the current starting address, the first hash value, and the second hash value into the target slot; The accumulation module is configured to increment the hit count in the corresponding linked list node by 1; Wherein, after all the starting addresses in the memory buffer are traversed, the update of the local overflow linked list is completed.

[0101] In some embodiments, the code block hit linked list generation sub-module includes: A local linked list acquisition module, configured to acquire the local hash table and the local overflow linked list corresponding to each memory buffer; A first merging module, configured to merge the local hash tables to generate a global hash table; A second merging module, configured to merge the local overflow linked lists to generate a global overflow linked list.

[0102] For the description of the features in the embodiments corresponding to the fault injection device, reference can be made to the relevant description of the embodiments corresponding to the fault injection method, which will not be elaborated here one by one.

[0103] An embodiment of the present invention further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above-mentioned embodiments of the fault injection method.

[0104] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is configured to execute the steps in any one of the above-mentioned embodiments of the fault injection method when running.

[0105] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media that can store computer programs, such as USB flash drives, read-only memory (ROM for short), random access memory (RAM for short), external hard drives, magnetic disks, or optical discs.

[0106] An embodiment of the present invention also provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the fault injection method.

[0107] An embodiment of the present invention also provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the fault injection method.

[0108] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0109] The above has introduced in detail a fault injection method, device, medium, and product provided by the present invention. Specific examples are used herein to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A fault injection method, characterized in that, Including: Create and execute multiple initial fault injection processes, and record the code block information of the code blocks corresponding to the fault injection during the execution of each of the initial fault injection processes; Generate a code block hit linked list according to each of the code block information; wherein, the code block hit linked list at least includes the hit times of each of the code blocks; Obtain the historical failure rates of each of the code blocks, and determine the priorities of the corresponding code blocks according to the code block hit linked list and each of the historical failure rates; Execute new fault injection processes based on each of the code blocks and their corresponding priorities.

2. The fault injection method according to claim 1, wherein Determine the priorities of the corresponding code blocks according to the code block hit linked list and each of the historical failure rates, including: Determine the code blocks corresponding to the hit times of 1 according to the code block hit linked list; Store the data structures of each of the code blocks corresponding to the hit times of 1 into the first hit linked list; Determine the code blocks corresponding to the hit times not equal to 1 according to the code block hit linked list; Store the data structures of each of the code blocks corresponding to the hit times not equal to 1 into the hot code block linked list; Determine the hot zone weight values of each of the code blocks in the hot code block linked list; Determine the priorities of each of the code blocks in the hot code block linked list according to each of the hot zone weight values; Wherein, the priorities of each of the code blocks in the first hit linked list are all higher than the priorities of each of the code blocks in the hot code block linked list; Correspondingly, execute new fault injection processes based on each of the code blocks and their corresponding priorities, including: Execute new fault injection processes in descending order according to the priorities of each of the code blocks in the first hit linked list and the hot code block linked list.

3. The fault injection method according to claim 2, wherein Determine the hot zone weight values of each of the code blocks in the hot code block linked list, including: Obtain the hit times and the maximum hit times of each of the code blocks in the hot code block linked list according to the code block hit linked list; Determine the code heat values of each of the code blocks according to the hit times and the maximum hit times of each of the code blocks in the hot code block linked list; Obtain multiple current system performance parameters, and determine the current system pressure value according to each of the system performance parameters; Perform weighted summation according to the historical failure rates, the code heat values and the current system pressure values of each of the code blocks in the hot code block linked list to determine the hot zone weight values of the corresponding code blocks.

4. The fault injection method according to claim 3, characterized in that Obtain multiple current system performance parameters, and determine the current system pressure value according to each of the system performance parameters, including: Collect the time ratios of the central processing unit in each state according to the first preset period; wherein, the states at least include the user state, the kernel state and the idle state; Determine the instantaneous central processing unit utilization rate according to the difference calculation method and each of the time ratios; Collect the total memory size, the current free memory size, the buffer memory size and the cache memory size of the memory according to the second preset period; Determine the used memory size according to the total memory size, the current free memory size, the buffer memory size and the cache memory size; Obtain the average total time consumption of the input / output requests, and obtain the system pressure value at the previous moment; Determine the current system pressure value according to the instantaneous central processing unit utilization rate, the used memory size, the total memory size, the average total elapsed time, and the system pressure value at the previous moment.

5. The fault injection method according to claim 4, wherein Determine the priorities of the code blocks in the hot spot code block linked list according to the respective hot zone weight values, including: Arrange the code blocks in the hot spot code block linked list in descending order according to the respective hot zone weight values to generate a hot zone injection queue; Split the hot zone injection queue into a first hot zone injection sub-queue and a second hot zone injection sub-queue; Arrange the code blocks in the first hot zone injection sub-queue in descending order according to the corresponding hot zone weight values to determine the priorities of the code blocks in the first hot zone injection sub-queue; Determine the priorities of the code blocks in the second hot zone injection sub-queue according to the weighted random algorithm and the hot zone weight values of the code blocks in the second hot zone injection sub-queue; Wherein, the hot zone weight values of the code blocks in the first hot zone injection sub-queue are all higher than the hot zone weight values of the code blocks in the second hot zone injection sub-queue; the priorities of the code blocks in the first hot zone injection sub-queue are all higher than the priorities of the code blocks in the second hot zone injection sub-queue.

6. The fault injection method according to claim 5, wherein Determine the priorities of the code blocks in the second hot zone injection sub-queue according to the weighted random algorithm and the hot zone weight values of the code blocks in the second hot zone injection sub-queue, including: Determine the probability distribution of the code blocks in the second hot zone injection sub-queue according to the hot zone weight values of the code blocks in the second hot zone injection sub-queue; Generate a cumulative probability table according to the probability distribution of the code blocks in the second hot zone injection sub-queue; Generate a random number and map the random number to a target interval; Locate the smallest index that meets the preset conditions according to the random number, the cumulative probability table, and the binary search method; Determine the corresponding code block in the second hot zone injection sub-queue according to the smallest index and add it to the polling algorithm queue; Return to the step of generating a random number and mapping the random number to the target interval until all the code blocks in the second hot zone injection sub-queue are added to the polling algorithm queue.

7. The fault injection method according to any one of claims 1 to 6, characterized in that Create and execute multiple initial fault injection processes, including: Create a dedicated control group corresponding to each of the initial fault injection processes based on the control group directory; Set the resource limits for the corresponding initial fault injection processes according to the respective dedicated control groups; wherein, the resource limits at least include central processing unit resource limits and memory resource limits; Create a corresponding memory buffer for each of the initial fault injection processes based on a preset kernel coverage measurement tool; Map each of the memory buffers to the virtual address space in the user state through the memory mapping system call function, and start the code coverage tracking function of the preset kernel coverage measurement tool.

8. The fault injection method according to claim 7, characterized in that, Record the code block information of the code blocks corresponding to the fault injections during the execution of each of the initial fault injection processes, including: Determine the starting address of the code block corresponding to the fault injection of the initial fault injection process; Store the starting address into the memory buffer corresponding to the initial fault injection process.

9. The fault injection method according to claim 8, wherein Generate a code block hit list according to each piece of code block information, including: Perform hash calculation on the starting addresses in each memory buffer respectively to determine the hit times of each starting address in each memory buffer; Determine the hit times of the code blocks corresponding to each initial fault injection process according to the hit times of each starting address in each memory buffer; Generate a code block hit list according to the hit times of the code blocks corresponding to each initial fault injection process.

10. The fault injection method according to claim 9, wherein Perform hash calculation on the starting addresses in each memory buffer respectively to determine the hit times of each starting address in each memory buffer, including: Select a current starting address from each starting address in the memory buffer; Determine the first hash value of the current starting address according to the first hash function and determine the second hash value of the current starting address according to the second hash function; Determine the main slot index according to the first hash value and determine the target slot corresponding to the current starting address in the locally created hash table according to the main slot index; Judge whether the target slot is empty; If it is confirmed that the target slot is empty, write the current starting address, the hit times corresponding to the current starting address, the first hash value and the second hash value into the target slot; If it is confirmed that the target slot is not empty, obtain the second hash value in the target slot; Judge whether the second hash value in the target slot is the same as the second hash value of the current starting address; If it is confirmed that the second hash value in the target slot is the same as the second hash value of the current starting address, set the hit times in the target slot to be incremented by 1; If it is confirmed that the second hash value in the target slot is not the same as the second hash value of the current starting address, determine the starting address corresponding to the target slot and execute the address conflict handling process according to the starting address corresponding to the target slot; Select a new current starting address from the remaining starting addresses in the memory buffer, return to the step of determining the first hash value of the current starting address according to the first hash function and determining the second hash value of the current starting address according to the second hash function, until all the starting addresses are traversed, and complete the update of the local hash table.

11. The fault injection method according to claim 10, characterized in that, Execute the address conflict handling process according to the starting address corresponding to the target slot, including: Judge whether there is a linked list node corresponding to the starting address corresponding to the target slot in the locally created local overflow linked list; If it is confirmed that there is no linked list node corresponding to the starting address corresponding to the target slot, create a target linked list node in the local overflow linked list; Write the starting address in the target slot, the hit times corresponding to the starting address, the first hash value and the second hash value into the target linked list node; Empty the target slot and write the current starting address, the hit times corresponding to the current starting address, the first hash value and the second hash value into the target slot; If it is confirmed that there is a linked list node corresponding to the starting address corresponding to the target slot, then increment the hit count in the corresponding linked list node by 1; Among them, after all the starting addresses in the memory buffer are traversed, the update of the local overflow linked list is completed.

12. The fault injection method according to claim 11, wherein Generate a code block hit linked list according to the hit counts of the code blocks corresponding to each of the initial fault injection processes, including: Obtain the local hash table and the local overflow linked list corresponding to each of the memory buffers; Merge the local hash tables to generate a global hash table; Merge the local overflow linked lists to generate a global overflow linked list.

13. An electronic device, characterized in that, Include: A memory for storing a computer program; A processor for implementing the steps of the fault injection method according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the fault injection method according to any one of claims 1 to 12 when executed by a processor.

15. A computer program product, comprising a computer program, characterized in that, The computer program implements the steps of the fault injection method according to any one of claims 1 to 12 when executed by a processor.

Images