Fault injection method, device, medium and product

Abstract

The present invention discloses a fault injection method, device, medium, and product, relating to the field of kernel testing technology. This solution creates and executes multiple initial fault injection processes, and during the execution of each initial fault injection process, records code block information corresponding to the fault-injected code block, facilitating the collection of the number of hits and historical failure rates of the code block. In other words, this solution simultaneously considers the changing trends of code heat and code failure during the fault injection process, and generates a strategy for the next round of fault injection based on this changing trend. Specifically, it determines the priority of fault injection for each code block, so that a new round of fault injection processes can be executed based on the priority of each code block. This effectively improves the testing efficiency of high-fault-rate modules, thereby more comprehensively revealing potential system problems.

Description

Technical Field

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

[0002] As computer systems become increasingly complex, the stability and fault tolerance of operating system kernels are crucial. This is especially true in scenarios like cloud computing, storage, and edge computing, where abnormal kernel module behavior can lead to serious consequences. To verify the kernel's robustness under extreme conditions, fault injection technology is widely used to simulate various failure scenarios. By actively injecting controllable fault signals, developers can trigger hidden code paths and evaluate the kernel's self-healing capabilities and fault propagation boundaries.

[0003] Currently, commonly used kernel fault injection tools are based on system calls, attempting to discover kernel vulnerabilities through mutation and serialization of system calls. They leverage code coverage information to guide test case generation and selection, thereby improving test efficiency and code coverage. However, this fault injection strategy, driven primarily by code coverage, prioritizes testing newly discovered paths, ignoring the impact of historical failure rates. For some modules, even if coverage meets requirements but the code has a high historical failure rate, this strategy fails to fully uncover systemic issues.

[0004] In view of the above, how to solve the problem that the current kernel fault injection strategy relies too much on code coverage and ignores historical failure rates, resulting in insufficient testing of high-failure-rate modules and an inability to fully reveal potential system problems, is an urgent problem that technicians in this field need to solve. 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 relies too much on code coverage and ignores historical failure rates, resulting in insufficient testing of high-failure-rate modules and an inability to fully reveal potential system problems.

[0006] The present invention provides a fault injection method, comprising:

[0007] Creating and executing multiple initial fault injection processes, and recording code block information of the corresponding fault injected code block during the execution of each initial fault injection process;

[0008] Generate a code block hit linked list based on the information of each code block; wherein the code block hit linked list at least includes the number of hits of each code block;

[0009] Obtain the historical failure rate of each code block, and determine the priority of the corresponding code block based on the code block hit list and each historical failure rate;

[0010] A new fault injection process is executed based on each code block and its corresponding priority.

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

[0012] The present invention also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned fault injection methods are implemented.

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

[0014] The beneficial effect of the present invention lies in that, 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 number of hits and historical failure rates of the code block; that is, this solution simultaneously considers the changing trends of the code heat situation and the code failure situation during the fault injection process, and generates a strategy for the next round of fault injection based on the changing trend, that is, determines the priority of the fault injection of each code block, so as to execute a new round of fault injection process according to the priority of each code block, which can effectively improve the testing efficiency of high fault rate modules, thereby more comprehensively revealing potential problems of the system.

[0015] In addition, the present invention also provides a fault injection device, medium and product, which have the same effects as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A flowchart of a fault injection method provided by an embodiment of the present invention;

[0018] Figure 2 A schematic diagram of a fault injection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0019] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0020] It should be noted that, in the description of the present invention, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. The terms "first," "second," etc., in the present invention are used to distinguish similar objects, and are not used to describe a particular order or precedence.

[0021] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0022] At present, commonly used kernel fault injection tools are based on system calls, and attempt to discover kernel vulnerabilities through the variation 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, and gives priority to testing newly discovered paths, ignoring the impact of historical failure rates. For some modules, the coverage may have reached the standard, but the historical failure rate of the code is high, and this strategy cannot fully explore system problems. Therefore, in order 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.

[0023] Figure 1 This is a flow chart of a fault injection method provided by an embodiment of the present invention. Figure 1 As shown, the method includes:

[0024] S10: creating and executing multiple initial fault injection processes, and recording code block information of a code block corresponding to the fault injection during the execution of each initial fault injection process.

[0025] Specifically, first, multiple initial fault injection processes are created, that is, processes that inject initial test cases into the kernel. When the program starts, the preset initial test case library is executed, the kernel basic execution path is triggered, and the initial code coverage data is generated. It should be noted that in this embodiment, the initial test case library should at least contain a combination of high-frequency system calls, such as file operations, process management, network communications, etc. It should also be noted that in this embodiment, multiple initial fault injection processes can be created at the same time, each process is executed concurrently, and resources do not interfere with each other. In this embodiment, there is no restriction on the specific creation process of the initial fault injection process.

[0026] At the same time, during the execution of each initial fault injection process, the code block information of the code block corresponding to the fault injection is recorded. 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 to enter or exit. These code blocks can be functions, methods, loops, conditional statements, etc., which perform specific tasks or operations during the execution of the program. In this embodiment, there is no restriction on the specific type of code block. In addition, in this embodiment, there is no restriction on the specific content of the code block information, for example, it may include basic information, function description, starting address, number of hits, and resource usage, etc., depending on the specific implementation situation.

[0027] S11: Generate a code block hit list according to the information of each code block.

[0028] The code block hit linked list at least includes the hit count of each code block.

[0029] Furthermore, after obtaining the code block information of each code block, a code block hit list is generated based on the code block information. It should be noted that the code block hit list at least includes the hit count of each code block. The hit count refers to the number of times a code block is executed in the corresponding process. In this embodiment, the specific content of the code block hit list is not limited. In addition to the hit count of the code block, it may also include other information about the code block.

[0030] 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 list and each historical failure rate.

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

[0032] Subsequently, the historical failure rate of each code block is obtained. In this embodiment, the historical failure rate of each code block can be directly obtained from the historical failure database or calculated. This embodiment does not limit the method for determining the historical failure rate. Simultaneously, the priority of the corresponding code block is determined based on the code block hit list and the historical failure rate.

[0033] It's worth noting that the priority of each code block serves as a reference for the order of the next round of fault injection. Among all code blocks, those with higher priorities will be injected with faults first in the next round of fault injection. This approach simultaneously considers the changing trends of code popularity and code faults during the fault injection process, and generates a strategy for the next round of fault injection based on these trends, effectively improving the testing efficiency of modules with high fault rates.

[0034] It should be noted that this embodiment does not restrict the specific process of determining the priority of the corresponding code block based on the code block hit list and the historical failure rates. At the same time, it does not restrict the specific process of executing a new fault injection process based on each code block and its corresponding priority. It depends on the specific implementation situation.

[0035] In this embodiment, multiple initial fault injection processes are created and executed, and code block information of the code blocks corresponding to the fault injection is recorded during the execution of each initial fault injection process to facilitate the collection of the hit count and historical failure rate of the code blocks. In other words, this solution simultaneously considers the changing trends of code popularity and code failure during the fault injection process, and generates a strategy for the next round of fault injection based on this changing trend. That is, it determines the priority of fault injection for each code block, so that a new round of fault injection processes can be executed according to the priority of each code block. This can effectively improve the testing efficiency of modules with high failure rates, thereby more comprehensively revealing potential problems in the system.

[0036] In order to create and execute multiple initial fault injection processes, based on the above embodiments, in some embodiments, multiple initial fault injection processes are created and executed, including:

[0037] S101: Creating a dedicated control group corresponding to each initial fault injection process based on the control group directory;

[0038] S102: Setting resource limits for the initial fault injection process according to each dedicated control group;

[0039] The resource limitation includes at least CPU resource limitation and memory resource limitation;

[0040] S103: Creating a corresponding memory buffer for each initial fault injection process based on a preset kernel coverage measurement tool;

[0041] S104: Mapping each memory buffer to the virtual address space of the user state through a memory mapping system call function, and starting a code coverage tracking function of a preset kernel coverage measurement tool.

[0042] Specifically, a dedicated control group is first created for each initial fault injection process based on the control group (cgroup) directory. Resource limits are then set for each dedicated control group. Note that resource limits include at least Central Processing Unit (CPU) and memory resource limits. For example, CPU quotas are set in the cpu.max file to limit the computing resources used by the fault injection process. Memory limits are set to a preset value by setting memory.max. Exceeding this limit triggers an Out of Memory (OOM) event to terminate the process. Other resource limits may also be included, depending on the specific implementation.

[0043] To enable code coverage tracing, first open the pre-configured kernel coverage measurement tool mapped to the system (such as the KCOV device) and set the tracing mode. Then, use the corresponding command (such as an ioctl command) to instruct the kernel to allocate a memory buffer of a specified size to store coverage data. The kernel pre-allocates a contiguous block of memory based on this parameter, and all subsequent coverage data will be written to this area.

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

[0045] In this way, the complete creation and execution of the initial fault injection process is achieved, so that the code block information can be completely collected and accurately saved.

[0046] Based on the above embodiments, in some embodiments, during the execution of each initial fault injection process, code block information of the code block corresponding to the fault injection is recorded, including:

[0047] S105: Determine the starting address of the fault injection code block corresponding to the initial fault injection process;

[0048] S106: Storing the starting address in a memory buffer corresponding to the initial fault injection process.

[0049] Specifically, during the execution of the initial fault injection process, each time a code block is executed, its corresponding starting address (program counter) is recorded. It can be understood that a code block is a section of code that is executed sequentially, without branches entering or exiting. For example, the two directions of a decision branch each count as a code block, and each code block corresponds to a unique program counter address. Finally, the starting address is stored in the memory buffer corresponding to the initial fault injection process.

[0050] In this embodiment, by determining the starting address of the fault-injected code block corresponding to the initial fault injection process and storing the starting address in the memory buffer corresponding to the initial fault injection process, the code block information is obtained and stored, so that the starting address can be used to determine the number of hits of each code block later.

[0051] Based on the above embodiments, in some embodiments, generating a code block hit list according to information of each code block includes:

[0052] S111: performing hash calculations on the start addresses in each memory buffer respectively to determine the number of hits for each start address in each memory buffer;

[0053] S112: Determine the hit count of the code block corresponding to each initial fault injection process according to the hit count of each start address in each memory buffer;

[0054] S113: Generate a code block hit linked list according to the hit counts of the code blocks corresponding to the initial fault injection processes.

[0055] To generate the code block hit list, in this embodiment, a hash calculation is performed on the starting address in each memory buffer to determine the number of hits for each starting address in each memory buffer. It should be noted that in this embodiment, there is no restriction on the hash algorithm used for the hash calculation and the number of calculations, which depends on the specific implementation.

[0056] The number of hits for each starting address in each memory buffer is then used to determine the number of hits for the code blocks corresponding to each initial fault injection process. Finally, a code block hit list is generated based on the number of hits for the code blocks corresponding to each initial fault injection process. This completes the generation of the code block hit list.

[0057] Considering that hash collisions may cause distortion in the coverage statistics of code blocks, in order to ensure the accurate generation of the code block hit list, in the specific implementation, hash calculations are performed on the starting addresses in each memory buffer to determine the hit count of each starting address in each memory buffer, including:

[0058] S114: Selecting a current starting address from each starting address in the memory buffer;

[0059] S115: Determine a first hash value of the current starting address according to the first hash function, and determine a second hash value of the current starting address according to the second hash function;

[0060] S116: Determine a primary slot index according to the first hash value, and determine a target slot corresponding to the current start address in a pre-created local hash table according to the primary slot index;

[0061] S117: Determine whether the target slot is empty; if so, proceed to step S118; if not, proceed to step S119;

[0062] S118: Write the current starting address, the number of hits corresponding to the current starting address, the first hash value, and the second hash value into the target slot;

[0063] S119: Obtain the second hash value in the target slot;

[0064] 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, proceed to step S121; if not, proceed to step S122;

[0065] S121: Set the number of hits in the target slot plus 1;

[0066] 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;

[0067] 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 the local hash table is updated.

[0068] In specific implementation, this solution proposes a double hash orthogonal verification method. First, a current starting address is selected from the starting addresses in the memory buffer. It is understood that the current starting address can be any starting address in the memory buffer. A first hash value of the current starting address is determined using a first hash function, and a second hash value of the current starting address is determined using a second hash function.

[0069] It should be noted that this embodiment does not limit the specific types of the first and second hash functions. For example, SHA-1 can be used as the first hash function, and the first 16 bits of the 128-bit output can be truncated as the first hash value. The second hash function can be an optimized variant of CRC32, and a 16-bit checksum can be generated using the 0xEDB88320 polynomial to obtain the second hash value.

[0070] Subsequently, the main slot index is determined based on the first hash value, and the target slot corresponding to the current starting address is determined in the pre-created local hash table based on the main slot index. It should be noted that the local hash table is a pre-created linked list corresponding to the memory buffer and used to store the number of hits for 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, each of which contains the corresponding starting address, the number of hits corresponding to the starting address, the first hash value, and the second hash value.

[0071] Further determine whether the target slot corresponding to the current starting address in the local hash table is empty. If the target slot is confirmed to be empty, it is considered that the number of hits for the current starting address is recorded for the first time. Specifically, the current starting address, the number of hits corresponding to the current starting address (1 time), the first hash value, and the second hash value are written to the target slot. If the target slot is confirmed to be 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, thereby determining whether there is a conflict between the current starting address and the starting address already in the target slot.

[0072] 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, then it is considered that the current starting address does not conflict with the starting address already in the target slot, and the two are the same. The number of hits 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 different from the second hash value of the current starting address, then it is considered that the current starting address does not conflict with the starting address already in the target slot, and the two are different. In this case, it is necessary to determine the starting address corresponding to the target slot, and execute the address conflict handling process based on the starting address corresponding to the target slot. It should be noted that the specific process of the address conflict handling process is not limited in this embodiment and depends on the specific implementation situation.

[0073] The above completes the storage of the hit count for the current start address. It is also necessary to store the hit counts for the remaining start addresses in the memory buffer. Specifically, a new current start address is selected from the remaining start addresses in the memory buffer, and the process returns to the steps of determining the first hash value of the current start address using the first hash function, and determining the second hash value of the current start address using the second hash function, until all start addresses are traversed and the local hash table is updated.

[0074] In order to implement address conflict handling, based on the above embodiments, this solution also provides a mechanism for overflow linked list management. Specifically, in some embodiments, the address conflict handling process is executed according to the starting address corresponding to the target slot, including:

[0075] S124: Determine whether there is a linked list node corresponding to the starting address corresponding to the target slot in the pre-created local overflow linked list; if not, proceed to step S125; if so, proceed to step S128;

[0076] S125: Create a target linked list node in the local overflow linked list;

[0077] S126: Write the starting address in the target slot, the number of hits corresponding to the starting address, the first hash value, and the second hash value into the target linked list node;

[0078] S127: Clear the target slot and write the current starting address, the number of hits corresponding to the current starting address, the first hash value, and the second hash value into the target slot;

[0079] S128: Add 1 to the number of hits in the corresponding linked list node;

[0080] Among them, after all the starting addresses in the memory buffer are traversed, the update of the local overflow linked list is completed.

[0081] 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, it is first determined whether there is a linked list node corresponding to the starting address corresponding to the target slot in the pre-created local overflow linked list. It can be understood that the local overflow linked list is a pre-created linked list corresponding to the memory buffer and used to store the number of hits of the conflicting starting address. 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, each of which contains the corresponding starting address, the number of hits corresponding to the starting address, the first hash value, and the second hash value.

[0082] If it is confirmed that there is no linked list node corresponding to the starting address corresponding to the target slot, then it is confirmed that the starting address corresponding to the target slot has not previously had an address conflict. It is necessary to create a target linked list node in the local overflow linked list and write the starting address in the target slot, the number of hits corresponding to the starting address, the first hash value, and the second hash value into the target linked list node. Then, the target slot is cleared and the current starting address (i.e., the address that conflicts with the starting address in the target slot), the number of hits corresponding to the current starting address, the first hash value, and the second hash value are written into the target slot, thereby achieving an overflow of the conflicting address.

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

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

[0085] In the above embodiment, the local hash table and local overflow list of a memory buffer are updated. In order to generate a global code block hit list, based on the above embodiment, in some embodiments, the code block hit list is generated according to the hit count of the code block corresponding to each initial fault injection process, including:

[0086] S131: Obtain the local hash table and local overflow linked list corresponding to each memory buffer;

[0087] S132: Merge the local hash tables to generate a global hash table;

[0088] S133: Merge the local overflow linked lists to generate a global overflow linked list.

[0089] Specifically, after determining the local hash table and local overflow list corresponding to each memory buffer, a global merge is performed to count the number of hits for each hash slot (starting address). When the fault injection thread terminates, the local hash table and local overflow list corresponding to each memory buffer are retrieved and merged to generate a global hash table. The local overflow lists are then merged to generate a global overflow list. It can be understood that the global hash table and global overflow list together constitute the code block hit list.

[0090] It should be noted that when merging the local hash tables, the update of the hit count for the same hash slot may be subject to competition, so the merging of the global hash tables requires the use of atomic operations. It should also be noted that the merging of the global hash table is similar to the merging of the local hash tables. When the main hash slot is hit for the first time, if the target slot is empty, the initial value of the hit count (1 time) is written. If the slot is occupied, the conflicting 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 updating process of the local hash table and the local overflow linked list in the above embodiment, it will not be repeated in this embodiment.

[0091] Based on the above embodiments, in some embodiments, the priority of a corresponding code block is determined according to the code block hit list and each historical failure rate, including:

[0092] S141: Determine the code block corresponding to the hit count of 1 according to the code block hit linked list;

[0093] S142: storing the data structure of each code block corresponding to a hit count of 1 into a first hit linked list;

[0094] S143: Determine, according to the code block hit linked list, a code block whose hit count is not 1;

[0095] S144: storing the data structure of each code block whose hit count is not 1 into a hot code block linked list;

[0096] S145: Determine the hot zone weight value of each code block in the hot code block chain list;

[0097] S146: Determine the priority of each code block in the hotspot code block chain list according to the weight value of each hot zone;

[0098] Among them, the priority of each code block in the first hit list is higher than the priority of each code block in the hot code block list;

[0099] To determine the priority of each code block, in this embodiment, the code block corresponding to the hit count of 1 is determined based on the code block hit list. That is, the code block with a hit count of 1 is obtained from the global hash table and the global overflow list. The data structure of each code block with a hit count of 1 is then stored in the first hit list.

[0100] The code blocks with a hit count not equal to 1 are further determined based on the code block hit 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 list. The data structure of each code block with a hit count not equal to 1 is then stored in the hot code block list.

[0101] It is worth noting that the priority of each code block in the first hit list is higher than the priority of each code block in the hot code block 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 list and the hot code block list. In other words, each code block in the first hit list must be injected with faults before each code block in the hot code block list to ensure rapid verification of the new path. It should also be noted that the priority of each code block in the first hit list is the same.

[0102] In order to further determine the priority of each code block in the hot code block chain list, it is necessary to determine the hot zone weight value of each code block in the hot code block chain list in a specific implementation, and determine the priority of each code block in the hot code block chain list based on the hot zone weight value. It should be noted that the priority of each code block in the hot code block chain list is different, and there is a sequence. In this embodiment, there is no restriction on the specific process of determining the hot zone weight value of each code block in the hot code block chain list and determining the priority of each code block in the hot code block chain list based on the hot zone weight value, and it depends on the specific implementation situation.

[0103] In this embodiment, the priority of each code block is preliminarily divided according to whether it is the first hit of each code block in the initial fault injection process, thereby improving the efficiency of priority division.

[0104] In order to determine the hot zone weight value of each code block in the hot code block list, this embodiment specifically constructs a code hot zone weight model based on the code heat value, historical failure rate and system pressure coefficient, thereby dynamically calculating the hot zone weight. Specifically, based on the above embodiment, in some embodiments, determining the hot zone weight value of each code block in the hot code block list includes:

[0105] S147: Obtain the hit count and maximum hit count of each code block in the hot code block chain list according to the code block hit chain list;

[0106] S148: Determine the code heat value of each code block according to the hit count and the maximum hit count of each code block in the hot code block linked list;

[0107] S149: Obtain multiple current system performance parameters, and determine the current system pressure value based on each system performance parameter;

[0108] S150: Perform weighted summation based on the historical failure rate, code heat value, and current system pressure value of each code block in the hot code block list to determine the hot zone weight value of the corresponding code block.

[0109] First, the hit count and maximum hit count for each code block in the hot code block list are obtained based on the code block hit list. It should be noted that the maximum hit count is the maximum hit count for all code blocks in the system. Furthermore, the code heat value of each code block is determined based on the hit count and maximum hit count for each code block in the hot code block list. The higher the code heat value, the greater the contribution of the hot zone weight value.

[0110] Subsequently, multiple current system performance parameters are obtained, and the current system pressure value is determined based on each system performance parameter. The larger the current system pressure value, the fewer available system resources and the smaller the contribution of the hot zone weight value. It should be noted that the calculation method of the current system pressure value is not limited in this embodiment.

[0111] Finally, a weighted sum is performed based on the historical failure rate, code heat value, and current system stress value of each code block in the hot code block list to determine the hot zone weight value of the corresponding code block. It can be understood that the greater the number of historical failures, the greater the contribution of the hot zone weight value, reflecting the stability risk of the function. The specific formula for calculating the hot zone weight value is as follows:

[0112] ;

[0113] in, is the hot zone weight value, is the number of hits of code block i, is the maximum number of hits, is the code heat value of the code block, is the number of historical fault triggering times of code block i, is the total number of fault triggers for all code blocks in the system, is the historical failure rate of code block i, For the current moment, is the current system pressure value, are all weight coefficients.

[0114] It should also be noted that The weight used to control the historical failure rate, The larger the value, the more the system relies on long-term fault statistics. It is suitable for scenarios with high stability requirements. The value range is usually 0.3~0.5. The weight used to control the real-time health status, The larger the value, the more the system focuses on current performance indicators (such as CPU and latency). Its value is usually 0.2~0.4. For example, in scenarios with high stability requirements such as financial scenarios, historical repeated failures should be avoided as much as possible. In this case, The value of (such as 0.4-0.6) strengthens the impact of historical failures and focuses on monitoring the payment signature verification module that has made errors. At the same time, it also reduces The value of (0.3→0.2) reduces the sensitivity to real-time fluctuations and avoids the accidental disconnection of core trading links.

[0115] In this embodiment, a code hot zone weight model is constructed based on the code heat value, historical failure rate and system pressure coefficient, so as to dynamically calculate the hot zone weight to facilitate dynamic adjustment of subsequent fault injection strategies.

[0116] Based on the above embodiments, in some embodiments, obtaining multiple current system performance parameters and determining the current system pressure value according to each system performance parameter includes:

[0117] S151: Collecting the time proportion of the central processing unit in each state according to a first preset period; wherein the state includes at least user state, kernel state and idle state;

[0118] S152: Determine the instantaneous CPU utilization rate based on the difference calculation method and the time proportions;

[0119] S153: collecting the total memory size, current free memory size, buffer memory size, and cache memory size of the memory according to the second preset period;

[0120] S154: Determine the used memory size based on the total memory size, the current free memory size, the buffer memory size, and the cache memory size;

[0121] S155: Obtain the average total time consumed by input and output requests, and obtain the system pressure value at the last moment;

[0122] S156: Determine the current system pressure value according to the instantaneous CPU utilization, the used memory size, the total memory size, the average total time consumption, and the system pressure value at the previous moment.

[0123] To determine the current system pressure value, in this embodiment, the time percentage of the CPU in each state is collected based on a first preset period, for example, by parsing the kernel exposed interface (such as / proc / stat). It should be noted that the state includes at least user state, kernel state, and idle state; at the same time, in this embodiment, there is no limit on the length of the first preset period, for example, it can be 100ms. Subsequently, the instantaneous CPU utilization is determined based on the difference calculation method and the various time percentages. Specifically, the difference between two adjacent data collected based on the first preset period is calculated to obtain the instantaneous CPU utilization. The specific formula is as follows:

[0124] ;

[0125] in, is the instantaneous CPU utilization, The difference between the CPU time consumed by two adjacent user-mode processes. It is the difference between the CPU time consumed by two adjacent kernel-mode processes. is the difference between two adjacent completely idle CPU times. It is the difference between two consecutive CPU idle times while waiting for I / O completion.

[0126] Furthermore, the total memory size, current free memory size, buffer memory size, and cache memory size of the memory are collected according to a second preset period, for example, by parsing an interface exposed by the kernel (such as / proc / meminfo). It should be noted that in this embodiment, there is no restriction on the size of the second preset period. Based on the total memory size, current free memory size, buffer memory size, and cache memory size, the used memory size is determined using the following formula:

[0127] ;

[0128] in, is the size of used memory, is the total memory size, is the current free memory size, is the buffer memory size, The cache memory size.

[0129] Then, the average total time taken by the input and output (IO) requests is obtained, and the system pressure value at the last moment is obtained. For example, the average total time taken by the IO requests in the system can be obtained through user-mode IO tools or by embedding probes in the kernel. .

[0130] Finally, the current system pressure value is determined based on the instantaneous CPU utilization, used memory size, total memory size, average total time consumption, and the system pressure value at the previous moment. The formula is as follows:

[0131] ;

[0132] in, is the current system pressure value, is a smoothing factor used to control the degree of influence of historical pressure values ​​on current pressure values ​​(value ranges from 0 to 1). is the system pressure value at the previous moment, The threshold of IO latency, used to normalize IO latency.

[0133] It should be noted that the above current system pressure value calculation formula is based on the exponential weighted moving average method, integrating multiple system core indicators and combining historical smoothing factors. Smoothing historical pressure data to prevent short-term fluctuations (such as instantaneous surges in CPU pressure) from affecting pressure values. The value of should be specific to the specific scenario. For example, if the system pressure is relatively stable, a value between 0.7 and 0.9 is recommended. For real-time metrics, the formula integrates key system resource indicators through normalization and weighted calculation. CPU utilization directly determines the saturation of computing resources, affecting request throughput and response latency, and has the highest weight (60%). Memory pressure, often caused by memory leaks, has a slower response but more serious consequences, and has the second highest weight (30%), effectively capturing the system's progressive risks. The impact of I / O latency is typically present in specific services (such as database queries), and current software systems typically mitigate its impact through caching and other means. Therefore, it is given a 10% weight. Furthermore, the formula employs normalization to ensure that various system metrics are weighted within the same range. CPU utilization is converted to a range of 0–1, and memory is normalized to map to the same range. Because I / O has a lower weight, to prevent extreme system anomalies from going undetected, segmented normalization is used to amplify the impact of latency exceeding the threshold, ensuring that potential serious I / O congestion risks are detected. The I / O latency threshold can be defined based on the actual hardware environment.

[0134] In summary, in this embodiment, by real-time collection of multi-dimensional resource indicators under the system and building 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.

[0135] In order to determine the priority of each code block in the hot code block chain list, this solution is specifically based on the hot code block, combined with the greedy algorithm and weighted polling method to realize the generation of fault injection strategy. Specifically, based on the above embodiment, in some embodiments, the priority of each code block in the hot code block chain list is determined according to the weight value of each hot zone, including:

[0136] S161: Arrange the code blocks in the hotspot code block list in descending order according to the weight value of each hotspot to generate a hotspot injection queue;

[0137] S162: Split the hot zone injection queue into a first hot zone injection sub-queue and a second hot zone injection sub-queue;

[0138] S163: 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 priority of the code blocks in the first hot zone injection sub-queue;

[0139] S164: Determine the priority of each code block in the second hot zone injection sub-queue according to a weighted random algorithm and the hot zone weight value of each code block in the second hot zone injection sub-queue;

[0140] Among them, the hot zone weight value of each code block in the first hot zone injection sub-queue is higher than the hot zone weight value of each code block in the second hot zone injection sub-queue; the priority of each code block in the first hot zone injection sub-queue is higher than the priority of each code block in the second hot zone injection sub-queue.

[0141] Specifically, the code blocks in the hot zone code block list are 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 top 100 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.

[0142] It should be noted that this embodiment does not restrict the specific splitting of hot zone injection queues. However, it is necessary to ensure that the hot zone weight value of each code block in the first hot zone injection sub-queue is higher than the hot zone weight value of each code block in the second hot zone injection sub-queue. For example, the hot zone injection queue To-100 can be split into the first hot zone injection sub-queue for the high-priority segment (for example, Top20) and the second hot zone injection sub-queue for the low-priority segment (for example, Top21-Top100).

[0143] Subsequently, a greedy algorithm is used to quickly process high-priority hot zone targets. Specifically, the code blocks (for example, Top20) in the first hot zone injection sub-queue are sorted in descending order according to the corresponding hot zone weight values ​​to determine the priority of each code block in the first hot zone injection sub-queue. Each time, the code block with the largest queue hot zone weight is directly selected for injection.

[0144] For the second hot zone injection sub-queue in the low-priority range (e.g., Top21-Top100), the priority of each code block in the second hot zone injection sub-queue is determined based on a 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 the priority of each code block in the second hot zone injection sub-queue. The following is a detailed description of the process for determining the priority of each code block in the second hot zone injection sub-queue:

[0145] Specifically, determining the priority of each code block in the second hot zone injection sub-queue according to the weighted random algorithm and the hot zone weight value of each code block in the second hot zone injection sub-queue includes:

[0146] 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;

[0147] S166: Generate a cumulative probability table based on the probability distribution of each code block in the second hot zone injection sub-queue;

[0148] S167: Generate a random number and map the random number to a target interval;

[0149] S168: Locate the minimum index that meets the preset conditions based on the random number, cumulative probability table, and binary search method;

[0150] S169: Determine the corresponding code block in the second hot zone injection sub-queue according to the minimum index and add it to the polling algorithm queue; return to step S167 until all code blocks in the second hot zone injection sub-queue are added to the polling algorithm queue.

[0151] First, based on the hot zone weights of each code block in the second hot zone injection subqueue (e.g., the Top21-Top100 hot zone, denoted as the set S = {s21, s22, ..., s100}), determine the probability distribution of each code block in the second hot zone injection subqueue. For example, using the Top21-Top100 hot zone as the second hot zone injection subqueue, the probability distribution formula is as follows:

[0152] ;

[0153] in, The probability value of code block i in the sub-queue (Top21-Top100) injected into the second hot zone, .

[0154] Then, based on the probability distribution of each code block injected into the sub-queue in the second hot zone, a cumulative probability table is generated:

[0155] ;

[0156] in, is the cumulative probability table. It can be understood that .

[0157] Further, generate Uniformly distributed random numbers in the range And map the random numbers to the target interval . Locate the minimum index that meets the preset conditions based on random numbers, cumulative probability table and binary search method, specifically in the cumulative probability table Use binary search to locate the content that satisfies The minimum index of , according to the minimum index Determine the corresponding code block in the second hot zone injection subqueue , and add it to the polling algorithm queue; return to step S167 until all code blocks in the second hot zone 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 and injected during fault injection.

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

[0159] To help those skilled in the art better understand the dynamic fault injection process provided by this solution, the following describes in detail the specific process of executing a new fault injection process based on each code block and its corresponding priority, based on the above embodiments:

[0160] Based on the three-level priority queues mentioned above, namely the first hit linked list, the first hot zone injection sub-queue (i.e., the greedy algorithm queue), and the second hot zone injection sub-queue (i.e., the weighted polling queue), the system dynamically selects code blocks as fault injection points in order of priority and generates a fault injection pattern. The specific steps are as follows:

[0161] 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), then disassemble the machine code into assembly instructions, and identify its internal key nodes (such as conditional branches, loop exits, and exception handling entries) through disassembly.

[0162] The system's scheduling strategy is to prioritize tasks that hit the linked list for the first time, and after completion, process tasks in the first hot zone injection subqueue and the second hot zone injection subqueue in turn; when the system pressure coefficient P(t) exceeds the threshold (e.g., P(t)>0.8), low-priority injection is suspended, and only the highest-priority task is retained. That is, processing tasks in the first and second hot zone injection subqueues is stopped, and only the code blocks in the first hit linked list are injected to avoid resource overload.

[0163] Furthermore, to achieve precise fault injection, the kernel probe is first dynamically mounted, specifically receiving parameters passed by the policy control layer and registering the probe at the starting address of the code block using Kprobe. The fault type is then dynamically configured. Specifically, in the Kprobe callback function, the key nodes identified by the probe match the predefined fault template, triggering the following error types:

[0164] (1) Return value tampering: forcing a function to return an error code (such as ENOMEM to simulate insufficient memory).

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

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

[0167] Finally, the code coverage rate during the fault injection test is captured in real time, the code heat value statistics are performed, and the code heat value data is fed back to facilitate the update of the code block hit list.

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

[0169] Figure 2 Schematic diagram of a fault injection device provided by an embodiment of the present invention. Figure 2 As shown, the device includes:

[0170] A first execution module 10 is configured to create and execute multiple initial fault injection processes, and record code block information of a code block corresponding to the fault injection during the execution of each initial fault injection process;

[0171] A generating module 11 is configured to generate a code block hit linked list based on information of each code block; wherein the code block hit linked list at least includes the number of hits of each code block;

[0172] Determination module 12, 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 list and each historical failure rate;

[0173] The second execution module 13 is configured to execute a new fault injection process based on each code block and its corresponding priority.

[0174] In some embodiments, the determination module 12 includes:

[0175] A first determining submodule is configured to determine a code block corresponding to a hit count of 1 according to a code block hit linked list;

[0176] A first storage submodule is configured to store the data structure of each code block corresponding to a hit count of 1 into a first hit linked list;

[0177] The second determining submodule is used to determine the code blocks whose corresponding hit count is not 1 according to the code block hit linked list;

[0178] The second storage module is used to store the data structure of each code block whose hit count is not 1 into the hot code block linked list;

[0179] The third determination submodule is used to determine the hot zone weight value of each code block in the hot code block chain list;

[0180] The fourth determination submodule is used to determine the priority of each code block in the hot code block chain list according to the weight value of each hot zone;

[0181] Among them, the priority of each code block in the first hit list is higher than the priority of each code block in the hot code block list;

[0182] Correspondingly, the second execution module 13 includes:

[0183] The fault injection submodule is used to execute the new fault injection process in descending order according to the priority of each code block in the first hit list and the hot code block list.

[0184] In some embodiments, the third determining submodule includes:

[0185] The first acquisition submodule is used to obtain the hit count and maximum hit count of each code block in the hot code block chain list according to the code block hit chain list;

[0186] A fifth determination submodule, configured to determine a code heat value of each code block based on the number of hits and the maximum number of hits of each code block in the hot code block linked list;

[0187] The second acquisition module is used to obtain multiple current system performance parameters and determine the current system pressure value according to each system performance parameter;

[0188] The weighted summation submodule is used to perform weighted summation based on the historical failure rate, code heat value and current system pressure value of each code block in the hot code block list to determine the hot zone weight value of the corresponding code block.

[0189] In some embodiments, the second acquisition module includes:

[0190] A first collection submodule is configured to collect a time percentage of the central processing unit in each state according to a first preset period; wherein the state includes at least a user state, a kernel state, and an idle state;

[0191] a sixth determining submodule, configured to determine the instantaneous CPU utilization rate based on a difference calculation method and each time proportion;

[0192] A second acquisition submodule is used to acquire the total memory size, current free memory size, buffer memory size and cache memory size of the memory according to a second preset period;

[0193] a seventh determining submodule, configured to determine a used memory size based on the total memory size, the current free memory size, the buffer memory size, and the cache memory size;

[0194] The third acquisition submodule is used to obtain the average total time consumed by input and output requests and the system pressure value at the previous moment;

[0195] The eighth determining submodule is configured to determine the current system pressure value according to the instantaneous CPU utilization, the used memory size, the total memory size, the average total time consumption, and the system pressure value at the previous moment.

[0196] In some embodiments, the fourth determining submodule includes:

[0197] The hot zone injection queue generation submodule is used to arrange the code blocks in the hot zone code block chain list in descending order according to the weight value of each hot zone to generate a hot zone injection queue;

[0198] A hot zone injection queue splitting submodule, configured to split the hot zone injection queue into a first hot zone injection sub-queue and a second hot zone injection sub-queue;

[0199] A first priority determination submodule, configured to arrange the code blocks in the first hot zone injection subqueue in descending order according to the corresponding hot zone weight values, so as to determine the priority of the code blocks in the first hot zone injection subqueue;

[0200] A second priority determination submodule, configured to determine the priority of each code block in the second hot zone injection subqueue according to a weighted random algorithm and a hot zone weight value of each code block in the second hot zone injection subqueue;

[0201] Among them, the hot zone weight value of each code block in the first hot zone injection sub-queue is higher than the hot zone weight value of each code block in the second hot zone injection sub-queue; the priority of each code block in the first hot zone injection sub-queue is higher than the priority of each code block in the second hot zone injection sub-queue.

[0202] In some embodiments, the second priority determination submodule includes:

[0203] a probability distribution determination submodule, configured to determine the probability distribution of each code block in the second hot zone injection subqueue according to the hot zone weight value of each code block in the second hot zone injection subqueue;

[0204] A cumulative probability table generating submodule, configured to generate a cumulative probability table according to the probability distribution of each code block injected into the second hot zone subqueue;

[0205] A mapping submodule, used to generate random numbers and map the random numbers to the target interval;

[0206] The positioning submodule is used to locate the minimum index that meets the preset conditions based on random numbers, cumulative probability table and binary search method;

[0207] The retrieval submodule is used to determine the corresponding code block in the second hot zone injection subqueue according to the minimum index and add it to the polling algorithm queue; trigger the mapping submodule until all code blocks in the second hot zone injection subqueue are added to the polling algorithm queue.

[0208] In some embodiments, the first execution module 10 includes:

[0209] A dedicated control group creation submodule is used to create a dedicated control group corresponding to each initial fault injection process based on the control group directory;

[0210] A resource restriction submodule is used to set resource restrictions for the corresponding initial fault injection process according to each dedicated control group; wherein the resource restrictions include at least CPU resource restrictions and memory resource restrictions;

[0211] A memory buffer creation submodule is used to create a corresponding memory buffer for each initial fault injection process based on a preset kernel coverage measurement tool;

[0212] The code coverage tracking submodule is used 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.

[0213] In some embodiments, the first execution module 10 includes:

[0214] A starting address determination submodule is used to determine the starting address of the fault injection code block corresponding to the initial fault injection process;

[0215] The starting address storage submodule is used to store the starting address in the memory buffer corresponding to the initial fault injection process.

[0216] In some embodiments, the generating module 11 includes:

[0217] A starting address hit count determination submodule is used to perform hash calculations on the starting addresses in each memory buffer respectively to determine the hit count of each starting address in each memory buffer;

[0218] A code block hit count determination submodule, configured to determine the hit count of the code block corresponding to each initial fault injection process based on the hit count of each starting address in each memory buffer;

[0219] The code block hit linked list generation submodule 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.

[0220] In some embodiments, the start address hit count determination submodule includes:

[0221] The current starting address selection submodule is used to select the current starting address from each starting address in the memory buffer;

[0222] a hash value calculation submodule, configured to determine a first hash value of the current starting address according to a first hash function, and to determine a second hash value of the current starting address according to a second hash function;

[0223] a target slot determination submodule, configured to determine a primary slot index according to the first hash value, and determine a target slot corresponding to the current start address in a pre-created local hash table according to the primary slot index;

[0224] A first judgment module is used to judge whether the target slot is empty; if the target slot is confirmed to be empty, the first writing module is triggered; if the target slot is confirmed to be not empty, the second hash value acquisition module is triggered;

[0225] A first writing module is used to write the current starting address, the number of hits corresponding to the current starting address, the first hash value and the second hash value into the target slot;

[0226] A second hash value acquisition module, configured to acquire a second hash value in a target slot;

[0227] a second determination module, configured to determine whether the second hash value in the target slot is identical to the second hash value of the current starting address; if it is determined that the second hash value in the target slot is identical to the second hash value of the current starting address, triggering the setting module; if it is determined that the second hash value in the target slot is different from the second hash value of the current starting address, triggering the address conflict handling module;

[0228] The setting module is used to set the number of hits in the target slot plus 1;

[0229] An 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;

[0230] The new current starting address selection submodule selects a new current starting address from the remaining starting addresses in the memory buffer, triggering the hash value calculation submodule until all starting addresses are traversed and the local hash table is updated.

[0231] In some embodiments, the address conflict handling module includes:

[0232] The third judgment module is used to determine whether there is a linked list node corresponding to the starting address corresponding to the target slot in the 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, the target linked list node creation submodule is triggered; if it is confirmed that there is a linked list node corresponding to the starting address corresponding to the target slot, the accumulation module is triggered;

[0233] The target linked list node creation submodule is used to create the target linked list node in the local overflow linked list;

[0234] A second writing module is used to write the starting address in the target slot, the number of hits corresponding to the starting address, the first hash value and the second hash value into the target linked list node;

[0235] A third writing module is used to clear the target slot and write the current starting address, the number of hits corresponding to the current starting address, the first hash value and the second hash value into the target slot;

[0236] The accumulation module is used to increase the number of hits in the corresponding linked list node by 1;

[0237] Among them, after all the starting addresses in the memory buffer are traversed, the update of the local overflow linked list is completed.

[0238] In some embodiments, the code block hit list generation submodule includes:

[0239] A local linked list acquisition module is used to obtain the local hash table and local overflow linked list corresponding to each memory buffer;

[0240] A first merging module, configured to merge the local hash tables to generate a global hash table;

[0241] The second merging module is used to merge the local overflow linked lists to generate a global overflow linked list.

[0242] For the description of the features in the embodiment corresponding to the fault injection device, reference can be made to the relevant description of the embodiment corresponding to the fault injection method, which will not be repeated here.

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

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

[0245] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0246] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned fault injection method embodiments are implemented.

[0247] An embodiment of the present invention further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned fault injection method embodiments are implemented.

[0248] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0249] The above describes in detail the fault injection method, device, medium, and product provided by the present invention. This document uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above examples is intended only to facilitate understanding of the method and core concepts of the present invention. It should be noted that those skilled in the art may make various improvements and modifications to the present invention without departing from the principles of the present invention, and such improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A fault injection method, characterized in that: include: Creating and executing multiple initial fault injection processes, and recording code block information of a code block 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 the code block information; wherein the code block hit linked list at least includes the hit count of each code block; Obtaining a historical failure rate of each of the code blocks, and determining a priority of the corresponding code block according to the code block hit linked list and each of the historical failure rates; executing a new fault injection process based on each of the code blocks and their corresponding priorities; Determining the priority of the corresponding code block according to the code block hit linked list and each of the historical failure rates includes: Determine the code block corresponding to a hit count of 1 according to the code block hit linked list; Storing the data structure of each code block corresponding to a hit count of 1 in a first hit linked list; Determine the code block whose corresponding hit count is not 1 according to the code block hit linked list; The data structure of each code block whose corresponding hit count is not 1 is stored in a hot code block linked list; Determine the hot zone weight value of each code block in the hot code block chain list; Determine the priority of each code block in the hotspot code block chain list according to the weight value of each hot zone; 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, a new fault injection process is executed based on each of the code blocks and their corresponding priorities, including: Execute new fault injection processes in descending order according to the priority of each code block in the first hit linked list and the hot code block linked list; Determining the hot zone weight value of each code block in the hot code block linked list includes: Obtaining the hit count and maximum hit count of each code block in the hot code block chain list according to the code block hit chain list; Determining the code heat value of each code block according to the hit count and the maximum hit count of each code block in the hot code block linked list; Obtaining multiple current system performance parameters, and determining a current system pressure value based on each of the system performance parameters; A weighted sum is performed based on the historical failure rate, the code heat value, and the current system pressure value of each code block in the hot code block list to determine the hot zone weight value corresponding to the code block.

2. The fault injection method according to claim 1, characterized in that: Obtaining multiple current system performance parameters and determining a current system pressure value based on each of the system performance parameters, including: Collecting the time proportion of the central processing unit in each state according to a first preset period; wherein the state includes at least user state, kernel state and idle state; Determine instantaneous CPU utilization based on a difference calculation method and each of the time proportions; 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; Determine the used memory size based on the total memory size, current free memory size, buffer memory size, and cache memory size; Get the average total time consumed by input and output requests, and obtain the system pressure value at the last moment; The current system pressure value is determined according to the instantaneous CPU utilization, the used memory size, the total memory size, the average total time consumption and the system pressure value at the last moment.

3. The fault injection method according to claim 2, characterized in that: Determining the priority of each code block in the hotspot code block linked list according to the weight value of each hot zone includes: Arranging the code blocks in the hotspot code block linked list in descending order according to the weight value of each hotspot to generate a hotspot injection queue; Splitting 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 priority of the code blocks in the first hot zone injection sub-queue; determining the priority of each of the code blocks in the second hot zone injection sub-queue according to a weighted random algorithm and the hot zone weight value of each of the code blocks in the second hot zone injection sub-queue; Among them, the hot zone weight value of each code block in the first hot zone injection sub-queue is higher than the hot zone weight value of each code block in the second hot zone injection sub-queue; the priority of each code block in the first hot zone injection sub-queue is higher than the priority of each code block in the second hot zone injection sub-queue.

4. The fault injection method according to claim 3, characterized in that: Determining the priority of each of the code blocks in the second hot zone injection sub-queue according to a weighted random algorithm and the hot zone weight value of each of the code blocks in the second hot zone injection sub-queue includes: determining a probability distribution of each of the code blocks in the second hot zone injection sub-queue according to the hot zone weight value of each of the code blocks in the second hot zone injection sub-queue; generating a cumulative probability table according to the probability distribution of each of the code blocks injected into the second hot zone sub-queue; generating a random number and mapping the random number to a target interval; Locating the minimum 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 minimum index and add the code block to the polling algorithm queue; Return to the step of generating a random number and mapping the random number to a target interval until all the code blocks in the second hot zone injection sub-queue are added to the polling algorithm queue.

5. The fault injection method according to any one of claims 1 to 4, characterized in that: Create and execute several initial fault injection processes, including: Creating an exclusive control group corresponding to each of the initial fault injection processes based on the control group directory; Setting resource limits corresponding to the initial fault injection process according to each of the dedicated control groups; wherein the resource limits include at least a CPU resource limit and a memory resource limit; Creating a corresponding memory buffer for each of the initial fault injection processes based on a preset kernel coverage measurement tool; Each of the memory buffers is mapped to the virtual address space of the user state through a memory mapping system call function, and the code coverage tracking function of the preset kernel coverage measurement tool is started.

6. The fault injection method according to claim 5, characterized in that: During the execution of each of the initial fault injection processes, code block information of the code block corresponding to the fault injection is recorded, including: Determining a starting address of the fault-injected code block corresponding to the initial fault injection process; The starting address is stored in the memory buffer corresponding to the initial fault injection process.

7. The fault injection method according to claim 6, characterized in that: Generating a code block hit linked list according to the code block information includes: Performing hash calculations on the start addresses in the memory buffers to determine the number of hits of the start addresses in the memory buffers; Determining the hit count of the code block corresponding to each of the initial fault injection processes according to the hit count of each of the start addresses in each of the memory buffers; A code block hit linked list is generated according to the hit counts of the code blocks corresponding to each of the initial fault injection processes.

8. The fault injection method according to claim 7, characterized in that: Performing hash calculations on the start addresses in each of the memory buffers to determine the number of hits of each of the start addresses in each of the memory buffers includes: Selecting a current starting address from each of the starting addresses in the memory buffer; Determine a first hash value of the current starting address according to a first hash function, and determine a second hash value of the current starting address according to a second hash function; Determine a primary slot index according to the first hash value, and determine a target slot corresponding to the current start address in a pre-created local hash table according to the primary slot index; Determine whether the target slot is empty; If it is determined that the target slot is empty, writing the current starting address, the number of hits 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, obtaining a second hash value in the target slot; Determine 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, then the number of hits in the target slot is increased by 1; If it is determined that the second hash value in the target slot is different from the second hash value of the current starting address, determining the starting address corresponding to the target slot, and performing an address conflict handling process according to the starting address corresponding to the target slot; 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 the starting addresses are traversed and the update of the local hash table is completed.

9. The fault injection method according to claim 8, characterized in that: An address conflict handling process is performed according to the starting address corresponding to the target slot, including: Determine whether there is a linked list node corresponding to the starting address corresponding to the target slot in the 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, creating a target linked list node in the local overflow linked list; Writing the starting address, the number of hits corresponding to the starting address, the first hash value, and the second hash value in the target slot into the target linked list node; Clear the target slot, and write the current starting address, the number of hits 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, the number of hits in the corresponding linked list node is increased by 1; After all the starting addresses in the memory buffer are traversed, the updating of the local overflow linked list is completed.

10. The fault injection method according to claim 9, characterized in that: Generating a code block hit linked list according to the hit counts of the code blocks corresponding to each of the initial fault injection processes includes: Obtain the local hash table and the local overflow linked list corresponding to each of the memory buffers; Merging the local hash tables to generate a global hash table; The local overflow linked lists are merged to generate a global overflow linked list.

11. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the fault injection method according to any one of claims 1 to 10 when executing the computer program.

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

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the fault injection method according to any one of claims 1 to 10 are implemented.

Images