US20100287412A1 - Software reliability test method using selective fault activation, test area restriction method, workload generation method and computing apparatus for testing software reliability using the same - Google Patents
Software reliability test method using selective fault activation, test area restriction method, workload generation method and computing apparatus for testing software reliability using the same Download PDFInfo
- Publication number
- US20100287412A1 US20100287412A1 US12/572,939 US57293909A US2010287412A1 US 20100287412 A1 US20100287412 A1 US 20100287412A1 US 57293909 A US57293909 A US 57293909A US 2010287412 A1 US2010287412 A1 US 2010287412A1
- Authority
- US
- United States
- Prior art keywords
- fault injection
- fault
- module
- target function
- caller
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3696—Methods or tools to render software testable
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4494—Execution paradigms, e.g. implementations of programming paradigms data driven
Definitions
- the following disclosure relates to a software reliability test method using selective fault activation, a test area restriction method, a workload generation method and a computing apparatus for testing software reliability using the same, and in particular, to a software reliability test method using selective fault activation, a test area restriction method, a workload generation method and a computing apparatus for testing software reliability using the same, which select any one of execution modules that dynamically reside in an Operating System (OS) (for example, a kernel area) having the dynamic loading functions of the execution modules and are independent in function terms, and injects a fault only into the selected execution module to test reliability.
- OS Operating System
- a software reliability test method using fault injection and workload generation has been used in the reliability test of various software, the availability test of a system or the benchmarking of a fault-tolerance system. This test method is also applied in the development of execution modules that are dynamically loaded, such as device driver.
- a fault injection scheme for software reliability test can be divided into a compile-time fault injection scheme and a runtime fault injection scheme.
- the compile-time fault injection scheme injects faults into the source code or assembly code of the target program.
- the program instruction must be modified before the program image is loaded and executed.
- the modified code alters the target program instructions, causing injection.
- the runtime fault injection scheme dynamically changes a specific register value or the result value of a specific operation while a program is being executed, allowing a fault to be injected.
- the compile-time fault injection scheme using the change of source codes allow a fault to be injected into a desired location, but it requires the change of source code, recompiling of changed source code, and execution of recompiled execution code. Moreover, when a user desires to change a fault injection location, the whole work process should be repeated.
- the runtime fault injection scheme may freely inject a fault without the change of the source code or recompilation.
- Such related art software reliability test method cannot inject a fault into the exact test area of a system specified by a user, but injects the fault into an entire system. Consequently, it is difficult to perform a detailed reliability test for each module of software. Moreover, it is difficult to generate intensive workload for the activation of an injected fault in consideration of the software operation characteristic of a test target.
- a software reliability test method using selective fault activation includes: registering a test target module; and injecting a fault into a fault injection target function when a caller of the fault injection target function is included in the registered module, in a case of calling the fault injection target function.
- a test area restriction method includes: collecting effectiveness check information including an address of a memory in which a module registered as a test target among a plurality of modules sharing a specific function is executed; determining whether a caller of a fault injection target function included in the specific function is included in the registered module on the basis of the collected effectiveness check information; and injecting a fault into the fault injection target function, when the caller is included in the registered module.
- a workload generation method for testing software reliability includes: receiving workload information corresponding to a module which is registered as a test target among a plurality of modules sharing a specific function; and generating a workload in the registered module on the basis of the received workload information.
- a computing apparatus includes: a plurality of modules operating in a kernel; and a fault injection executor existing in the kernel, registering a designated module among the modules as a test target module, and injecting a fault into a fault injection target function when the fault injection target function is called by the registered module.
- FIG. 1 is a block diagram illustrating a software reliability test system using selective fault activation according to an exemplary embodiment.
- FIG. 2 is a flowchart illustrating a software reliability test method using selective fault activation according to an exemplary embodiment.
- FIG. 3 is a flowchart illustrating a test area restriction method for a software reliability test according to an exemplary embodiment.
- FIG. 4 is a flowchart illustrating a workload generation method in a test target module for a software reliability test according to an exemplary embodiment.
- FIG. 1 is a block diagram illustrating a software reliability test system using selective fault activation according to an exemplary embodiment.
- FIG. 2 is a flowchart illustrating a software reliability test method using selective fault activation according to an exemplary embodiment.
- a software reliability test system 100 using selective fault activation includes a fault injection unit 110 , a fault injection executer 120 , and a workload generation unit 130 .
- the fault injection unit 110 includes a fault injection executer generator 111 , and receives information related to fault injection from a user.
- the information related to fault injection may include modules that are designated as test targets, fault types to be generated in the designated modules, resident time limit of the fault injection executer 120 in a kernel, and the user designation activation pattern of fault injection.
- the fault types to be generated in the designated module may include memory allocation and page allocation that are selected by a user. For example, when the user would like a fault to be generated in the memory allocation of the designated module, the user may select the memory allocation as the fault type to be generated in the designated module.
- the user designation activation pattern of fault injection may include the number of fault injection for the selected fault type.
- the user may set the number of times a fault is injected when a memory is allocated. For example, the user may set a fault to be injected each time the memory allocation is performed, or the user may set a fault to be injected every five times the memory allocation is performed.
- the fault injection executor generator 111 dynamically generates the source code of the fault injection executer 120 that may inject a fault of the fault type designated by the user into a designated module, compiles the generated source code into a dynamic loading kernel module, and loads the compiled code in a kernel.
- the fault injection unit 110 collects the function symbol information of a designated module, and the fault injection executor generator 111 transfers a fault injection location to the fault injection executor 120 on the basis of the collected symbol information.
- the collected symbol information may include symbols that are used in a designated target module 150 , and address information corresponding to the symbols.
- Functions 140 are used when coding a source code for a designated module, and addresses are respectively given to the used functions 140 when the used functions 140 are respectively converted into execution codes (for example, when the used functions are compiled). More specifically, when a memory allocation function and a disk access function are used in the source coding of the designated module, the fault injection unit 110 may collect the symbol information of a target module 150 because the converted execution code includes the address of the memory allocation function and the address of the disk access function.
- the fault injection executor generator 111 automatically generates an execution code in order for the fault injection executor 120 to register a fault injection processing handler for processing of a fault injection target function on the basis of the collected symbol information. Accordingly, an operation, checking whether a called function is the fault injection target function, is performed in the fault injection processing handler on the basis of the symbol information. Since this operation is merely a check operation, it may be omitted.
- the fault injection unit 110 sets the resident time limit of the dynamically-loaded fault injection executor 120 in a kernel, and checks whether the resident time exceeds the resident time limit.
- the fault injection unit 110 terminates the fault injection executor 120 that is operating in the kernel.
- the resident time limit in the kernel may basically be the maximum time limit of a reliability test for a designated module, and may also be the time limit for preventing the fault injection executor 120 from limitlessly operating (for example, that in which a test gets into an infinite loop).
- the fault injection unit 110 may autonomously determine a resident time in the kernel when the resident time limit of the fault injection executor 120 in the kernel is not provided from a user.
- the fault injection executor 120 receives information of a module that is designated as a test target, from the fault injection unit 110 .
- the fault injection executor 120 registers the information of the module, designated as the test target, in its own state variable on the basis of the received information.
- the fault injection executor 120 collects effectiveness check information from the kernel for checking whether it is required to activate the fault injection of a registered module.
- the effectiveness check information is the address of a memory in which a module designated as a test target is executed.
- the fault injection executor 120 registers a fault injection processing handler that processes the activation of selective fault injection.
- the fault injection executor 120 which is dynamically loaded in the kernel, may register the fault injection processing handler for injecting a fault into a function (for example, malloc) of performing an operation (for example, memory allocation) that is selected as a fault type by a user on the basis of fault types included in fault injection-related information.
- a function for example, malloc
- an operation for example, memory allocation
- the fault injection executor 120 is changed into a fault injection standby state.
- the workload generation unit 130 receives workload generation information that is analyzed on the basis of a fault type and a designated module from the fault injection unit 110 , and generates a workload efficiently and intensively.
- a fault injection target function among functions shared by a plurality of modules is executed to reach a fault injection location that is predetermined in a called function
- the fault injection executor 120 that is in the fault injection standby state is changed into a fault injection operation state.
- the fault injection executor 120 registers a module designated by a user as a test target on the basis of information that is transferred from the user, among a plurality of modules sharing a specific function in operation S 210 .
- the fault injection executor 120 checks whether a designated module exists in a kernel, before registering the designated module as a test target in operation S 200 .
- the fault injection executor 120 ends a software reliability test.
- the fault injection executor 120 collects effectiveness check information for checking whether it is required to activate the selective fault injection for the registered target module 150 in operation S 220 .
- the effectiveness check information may be basically collected on the basis of module state information in the kernel.
- a shared function 140 for fault injection is called in a system, it may be used as information for checking whether the activation of fault injection is required in operation S 270 .
- the fault injection executor 120 collects information for the effectiveness check of a target module 150 , and when a fault injection target function among specific functions shared by the plurality of modules is called, the fault injection executor 120 registers a fault injection processing handler for executing fault injection in operation S 230 .
- the register location of the fault injection processing handler may be set on the basis of information that is analyzed in association with a fault type by the fault injection unit 110 .
- the fault injection unit 110 determines whether fault injection should be continuously performed through the fault injection executor 120 in operation S 240 . This determination is based on the predetermined resident time limit of the fault injection executor 120 in the kernel. For example, when the resident time exceeds the resident time limit, the fault injection unit 110 may terminates the fault injection executor 120 that is operating in the kernel.
- the fault injection executor 120 changes into a standby state in which fault injection may be performed in operation S 250 .
- the fault injection executor 120 changes into a fault injection operation state. A detailed description associated with the workload generation of the workload generation unit 130 will be described with reference to FIG. 4 .
- the fault injection executor 120 that is in the changed fault injection operation state determines whether the shared function 140 is a fault injection target function in operation S 260 .
- the fault injection processing handler of the fault injection executor 120 may determine whether to activate fault injection based on information of a caller that calls the memory allocation function because the memory allocation function may be called by other modules existing on the kernel as well as a module registered as a test target.
- the fault injection processing handler of the fault injection executor 120 checks whether it satisfies the fault injection condition set by a user in operation S 270 , and injects a fault into fault injection location in operation S 280 .
- the fault injection processing handler of the fault injection executor 120 returns a fault value instead of a normal result value based on the execution of the called function.
- the fault injection condition for controlling the fault injection pattern in detail may include fault injection intervals, a fault injection maximum frequency and flags. For example, in a case where fault injection condition is set to inject a fault when a memory allocation flag is set as 1, although the memory allocation function is set as the fault injection target function, the fault is not injected when a memory allocation flag is not 1.
- the fault injection processing handler of the fault injection executor 120 returns the normal result value of the called function in operation S 290 .
- the software reliability test may be performed in detail by injecting the fault into the selected location of the designated module.
- FIG. 3 is a flowchart illustrating a test area restriction method for a software reliability test according to an exemplary embodiment.
- the fault injection processing handler of the fault injection executor 120 obtains the address of a caller in operation S 271 .
- a function call mechanism is based on a stack.
- a system maintains a stack per software, and maintains a buffer (for example, a stack frame) corresponding to a function. Whenever the function is called, the address of the caller is stored in the buffer. That is, the system may store the address of a caller function in a buffer corresponding to the called function.
- the fault injection processing handler may trace a value, which is stored in a buffer corresponding to a called function, to obtain the caller address.
- the fault injection processing handler of the fault injection executor 120 checks the effectiveness of the caller address in operation S 272 .
- the effectiveness check is for checking whether the caller address is stored in the buffer of the called function.
- an operation of checking effectiveness designates a fault injection activation flag as 0 and is ended in operation S 276 .
- the flag is 0, the fault injection processing handler does not inject a fault into a fault injection target function.
- the fault injection processing handler of the fault injection executor 120 determines whether the caller address is included in the execution address of a module registered as a test target, i.e., the address of a memory in which the module registered as the test target is executed, on the basis of the effectiveness check information of the module registered as the test target in operation S 273 .
- the fault injection processing handler of the fault injection executor 120 returns to operation S 271 of obtaining the fore caller address. This return operation is repeated until a caller address is not effective or the caller address is included in the execution address of a test target module 150 .
- the fault injection processing handler of the fault injection executor 120 checks whether the fault injection condition set by a user is satisfied in operation S 274 .
- the fault injection processing handler of the fault injection executor 120 designates a fault injection activation flag as 0 based on the result value of the effectiveness check and is ended in operation S 276 .
- the fault injection processing handler of the fault injection executor 120 designates a fault injection activation flag as 1 based on the result value of the effectiveness check and is ended in operation S 275 .
- the flag is 1, the fault injection processing handler injects a fault into the fault injection target function.
- the fault injection executor 120 may inject a fault only into the location of a module that is selected as a test target among a plurality of modules sharing a specific function. Accordingly, it prevents the fault from being injected into an undesired location (for example, another module instead of a designated module), and the software reliability test is performed in a selected location efficiently.
- FIG. 4 is a flowchart illustrating a workload generation method in a test target module 150 for a software reliability test according to an exemplary embodiment.
- the workload generation unit 130 receives workload generation information that is analyzed on the basis of a fault type and a designated module in operation S 300 .
- the workload generation unit 130 may receive the workload generation information inputted from a user, through the fault injection unit 110 , or may directly receive workload generation information from the user.
- the workload generation information may include a designated module and its fault injection location information.
- the workload generation unit 130 generates a workload in a target module 150 based on the received workload generation information.
- the workload generation unit 130 composes a workload generation scenario for a workload to be generated on the basis of the workload generation information in operation S 310 .
- the workload may be intensively generated in order for a function corresponding to a fault injection location to be executed in operation S 320 .
- the workload generation is for executing a function (for example, a fault injection target function) corresponding to the fault injection location of a target module 150 through the operation of the a designated module, and the workload generation unit 130 may replace the role of an application program in a scheme similar to a scheme of requesting the performance of a function to a target module 150 in the application program.
- a function for example, a fault injection target function
- Intensive workload generation may increase the frequency of requesting the execution of the function to the target module 150 than the frequency of requesting under a normal operation instead of a software test. For example, if the request is performed once under the normal operation, the request may be performed a hundred times under the intensive workload generation.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
Provided are a software reliability test method using selective fault activation, a test area restriction method, a workload generation method and a computing apparatus for testing software reliability using the same. The software reliability test method registers a test target module. The software reliability test method injects a fault into a fault injection target function when a caller of the fault injection target function is included in the registered module, in a case of calling the fault injection target function.
Description
- This application claims priority under 35 U.S.C. §119 to Korean Patent Application No. 10-2007-0040283, filed on May 8, 2009, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety.
- The following disclosure relates to a software reliability test method using selective fault activation, a test area restriction method, a workload generation method and a computing apparatus for testing software reliability using the same, and in particular, to a software reliability test method using selective fault activation, a test area restriction method, a workload generation method and a computing apparatus for testing software reliability using the same, which select any one of execution modules that dynamically reside in an Operating System (OS) (for example, a kernel area) having the dynamic loading functions of the execution modules and are independent in function terms, and injects a fault only into the selected execution module to test reliability.
- A software reliability test method using fault injection and workload generation has been used in the reliability test of various software, the availability test of a system or the benchmarking of a fault-tolerance system. This test method is also applied in the development of execution modules that are dynamically loaded, such as device driver.
- A fault injection scheme for software reliability test can be divided into a compile-time fault injection scheme and a runtime fault injection scheme.
- The compile-time fault injection scheme injects faults into the source code or assembly code of the target program. To inject faults, the program instruction must be modified before the program image is loaded and executed. The modified code alters the target program instructions, causing injection.
- The runtime fault injection scheme dynamically changes a specific register value or the result value of a specific operation while a program is being executed, allowing a fault to be injected.
- The compile-time fault injection scheme using the change of source codes allow a fault to be injected into a desired location, but it requires the change of source code, recompiling of changed source code, and execution of recompiled execution code. Moreover, when a user desires to change a fault injection location, the whole work process should be repeated.
- On the contrary, the runtime fault injection scheme may freely inject a fault without the change of the source code or recompilation. However, it is difficult to dynamically change the result value of a corresponding function to inject a fault only for the test target when the modules of a system share a specific function. That is, this scheme is suitable for the test of the entire system, but there are some limitations when only the specific portion of the system is tested.
- Such related art software reliability test method cannot inject a fault into the exact test area of a system specified by a user, but injects the fault into an entire system. Consequently, it is difficult to perform a detailed reliability test for each module of software. Moreover, it is difficult to generate intensive workload for the activation of an injected fault in consideration of the software operation characteristic of a test target.
- In one general aspect, a software reliability test method using selective fault activation includes: registering a test target module; and injecting a fault into a fault injection target function when a caller of the fault injection target function is included in the registered module, in a case of calling the fault injection target function.
- In another general aspect, a test area restriction method includes: collecting effectiveness check information including an address of a memory in which a module registered as a test target among a plurality of modules sharing a specific function is executed; determining whether a caller of a fault injection target function included in the specific function is included in the registered module on the basis of the collected effectiveness check information; and injecting a fault into the fault injection target function, when the caller is included in the registered module.
- In another general aspect, a workload generation method for testing software reliability includes: receiving workload information corresponding to a module which is registered as a test target among a plurality of modules sharing a specific function; and generating a workload in the registered module on the basis of the received workload information.
- In another general aspect, a computing apparatus includes: a plurality of modules operating in a kernel; and a fault injection executor existing in the kernel, registering a designated module among the modules as a test target module, and injecting a fault into a fault injection target function when the fault injection target function is called by the registered module.
- Other features and aspects will be apparent from the following detailed description, the drawings, and the claims.
-
FIG. 1 is a block diagram illustrating a software reliability test system using selective fault activation according to an exemplary embodiment. -
FIG. 2 is a flowchart illustrating a software reliability test method using selective fault activation according to an exemplary embodiment. -
FIG. 3 is a flowchart illustrating a test area restriction method for a software reliability test according to an exemplary embodiment. -
FIG. 4 is a flowchart illustrating a workload generation method in a test target module for a software reliability test according to an exemplary embodiment. - Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings. Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated for clarity, illustration, and convenience. The following detailed description is provided to assist the reader in gaining a comprehensive understanding of the methods, apparatuses, and/or systems described herein. Accordingly, various changes, modifications, and equivalents of the methods, apparatuses, and/or systems described herein will be suggested to those of ordinary skill in the art. Also, descriptions of well-known functions and constructions may be omitted for increased clarity and conciseness. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
- A software reliability test system and method using selective fault activation according to an exemplary embodiment will be described with reference to
FIGS. 1 and 2 .FIG. 1 is a block diagram illustrating a software reliability test system using selective fault activation according to an exemplary embodiment.FIG. 2 is a flowchart illustrating a software reliability test method using selective fault activation according to an exemplary embodiment. - Referring to
FIG. 1 , a softwarereliability test system 100 using selective fault activation according to an exemplary embodiment includes afault injection unit 110, afault injection executer 120, and aworkload generation unit 130. - The
fault injection unit 110 includes a faultinjection executer generator 111, and receives information related to fault injection from a user. - The information related to fault injection may include modules that are designated as test targets, fault types to be generated in the designated modules, resident time limit of the
fault injection executer 120 in a kernel, and the user designation activation pattern of fault injection. - The fault types to be generated in the designated module may include memory allocation and page allocation that are selected by a user. For example, when the user would like a fault to be generated in the memory allocation of the designated module, the user may select the memory allocation as the fault type to be generated in the designated module.
- The user designation activation pattern of fault injection may include the number of fault injection for the selected fault type. The user may set the number of times a fault is injected when a memory is allocated. For example, the user may set a fault to be injected each time the memory allocation is performed, or the user may set a fault to be injected every five times the memory allocation is performed.
- The fault
injection executor generator 111 dynamically generates the source code of thefault injection executer 120 that may inject a fault of the fault type designated by the user into a designated module, compiles the generated source code into a dynamic loading kernel module, and loads the compiled code in a kernel. - For example, the
fault injection unit 110 collects the function symbol information of a designated module, and the faultinjection executor generator 111 transfers a fault injection location to thefault injection executor 120 on the basis of the collected symbol information. The collected symbol information may include symbols that are used in a designatedtarget module 150, and address information corresponding to the symbols. -
Functions 140 are used when coding a source code for a designated module, and addresses are respectively given to theused functions 140 when theused functions 140 are respectively converted into execution codes (for example, when the used functions are compiled). More specifically, when a memory allocation function and a disk access function are used in the source coding of the designated module, thefault injection unit 110 may collect the symbol information of atarget module 150 because the converted execution code includes the address of the memory allocation function and the address of the disk access function. The faultinjection executor generator 111 automatically generates an execution code in order for thefault injection executor 120 to register a fault injection processing handler for processing of a fault injection target function on the basis of the collected symbol information. Accordingly, an operation, checking whether a called function is the fault injection target function, is performed in the fault injection processing handler on the basis of the symbol information. Since this operation is merely a check operation, it may be omitted. - The
fault injection unit 110 sets the resident time limit of the dynamically-loadedfault injection executor 120 in a kernel, and checks whether the resident time exceeds the resident time limit. - When the resident time of the
fault injection executor 120 exceeds the resident time limit in the kernel, thefault injection unit 110 terminates thefault injection executor 120 that is operating in the kernel. Herein, the resident time limit in the kernel may basically be the maximum time limit of a reliability test for a designated module, and may also be the time limit for preventing thefault injection executor 120 from limitlessly operating (for example, that in which a test gets into an infinite loop). - The
fault injection unit 110 may autonomously determine a resident time in the kernel when the resident time limit of thefault injection executor 120 in the kernel is not provided from a user. - The
fault injection executor 120 receives information of a module that is designated as a test target, from thefault injection unit 110. Thefault injection executor 120 registers the information of the module, designated as the test target, in its own state variable on the basis of the received information. - The
fault injection executor 120 collects effectiveness check information from the kernel for checking whether it is required to activate the fault injection of a registered module. Herein, the effectiveness check information is the address of a memory in which a module designated as a test target is executed. - The
fault injection executor 120 registers a fault injection processing handler that processes the activation of selective fault injection. For example, thefault injection executor 120, which is dynamically loaded in the kernel, may register the fault injection processing handler for injecting a fault into a function (for example, malloc) of performing an operation (for example, memory allocation) that is selected as a fault type by a user on the basis of fault types included in fault injection-related information. - When the above-described operations are completed, the
fault injection executor 120 is changed into a fault injection standby state. - The
workload generation unit 130 receives workload generation information that is analyzed on the basis of a fault type and a designated module from thefault injection unit 110, and generates a workload efficiently and intensively. - When a designated module reaches a fault injection point according to a workload generated by the
workload generation unit 130, i.e., a fault injection target function among functions shared by a plurality of modules is executed to reach a fault injection location that is predetermined in a called function, thefault injection executor 120 that is in the fault injection standby state is changed into a fault injection operation state. - The operation of the
fault injection executor 120 and a software reliability test method will be described below in more detail with reference toFIG. 2 . - Referring to
FIG. 2 , thefault injection executor 120 registers a module designated by a user as a test target on the basis of information that is transferred from the user, among a plurality of modules sharing a specific function in operation S210. - The
fault injection executor 120 checks whether a designated module exists in a kernel, before registering the designated module as a test target in operation S200. - When the designated module does not exist in the kernel, the
fault injection executor 120 ends a software reliability test. - After the registration of the
test target module 150 in operation S210, thefault injection executor 120 collects effectiveness check information for checking whether it is required to activate the selective fault injection for the registeredtarget module 150 in operation S220. When the test target is a kernel module, the effectiveness check information may be basically collected on the basis of module state information in the kernel. When a sharedfunction 140 for fault injection is called in a system, it may be used as information for checking whether the activation of fault injection is required in operation S270. - The
fault injection executor 120 collects information for the effectiveness check of atarget module 150, and when a fault injection target function among specific functions shared by the plurality of modules is called, thefault injection executor 120 registers a fault injection processing handler for executing fault injection in operation S230. Herein, the register location of the fault injection processing handler may be set on the basis of information that is analyzed in association with a fault type by thefault injection unit 110. - When the registration of the fault injection processing handler for processing the fault injection target function is completed, the
fault injection unit 110 determines whether fault injection should be continuously performed through thefault injection executor 120 in operation S240. This determination is based on the predetermined resident time limit of thefault injection executor 120 in the kernel. For example, when the resident time exceeds the resident time limit, thefault injection unit 110 may terminates thefault injection executor 120 that is operating in the kernel. - However, when the resident time does not exceed the resident time limit, the
fault injection executor 120 changes into a standby state in which fault injection may be performed in operation S250. When a workload is generated in a module that is registered as a test target by theworkload generation unit 130 and thereby a shared function is called, thefault injection executor 120 changes into a fault injection operation state. A detailed description associated with the workload generation of theworkload generation unit 130 will be described with reference toFIG. 4 . - The
fault injection executor 120 that is in the changed fault injection operation state determines whether the sharedfunction 140 is a fault injection target function in operation S260. - For example, when the called shared
function 140 is a memory allocation function and the memory allocation function is the fault injection target function, the fault injection processing handler of thefault injection executor 120 may determine whether to activate fault injection based on information of a caller that calls the memory allocation function because the memory allocation function may be called by other modules existing on the kernel as well as a module registered as a test target. - When the called shared
function 140 is the fault injection target function, determination of whether to actually inject a fault is performed through an operation S270 of checking the fault injection effectiveness of atarget module 150 in the fault injection processing handler. An operation of injecting a fault into atest target module 150 will be described in detail with reference toFIG. 3 , and is described in brief here. - When the caller of the function is included in the module registered as the test target in operation S260, the fault injection processing handler of the
fault injection executor 120 checks whether it satisfies the fault injection condition set by a user in operation S270, and injects a fault into fault injection location in operation S280. The fault injection processing handler of thefault injection executor 120 returns a fault value instead of a normal result value based on the execution of the called function. - The fault injection condition for controlling the fault injection pattern in detail may include fault injection intervals, a fault injection maximum frequency and flags. For example, in a case where fault injection condition is set to inject a fault when a memory allocation flag is set as 1, although the memory allocation function is set as the fault injection target function, the fault is not injected when a memory allocation flag is not 1.
- However, when the caller of the function is not included in the designated module in operation S260, the fault injection processing handler of the
fault injection executor 120 returns the normal result value of the called function in operation S290. - In this way, the software reliability test may be performed in detail by injecting the fault into the selected location of the designated module.
- The following description will be made in detail with reference to
FIG. 3 on a method for checking whether a fault injection condition is satisfied in atest target module 150 for a software reliability test according to an exemplary embodiment.FIG. 3 is a flowchart illustrating a test area restriction method for a software reliability test according to an exemplary embodiment. - Referring to
FIG. 3 , the fault injection processing handler of thefault injection executor 120 obtains the address of a caller in operation S271. - A function call mechanism is based on a stack. A system maintains a stack per software, and maintains a buffer (for example, a stack frame) corresponding to a function. Whenever the function is called, the address of the caller is stored in the buffer. That is, the system may store the address of a caller function in a buffer corresponding to the called function.
- Accordingly, the fault injection processing handler may trace a value, which is stored in a buffer corresponding to a called function, to obtain the caller address.
- The fault injection processing handler of the
fault injection executor 120 checks the effectiveness of the caller address in operation S272. Herein, the effectiveness check is for checking whether the caller address is stored in the buffer of the called function. When the caller address is not effective (for example, when there are no more caller addresses to be checked), an operation of checking effectiveness designates a fault injection activation flag as 0 and is ended in operation S276. When the flag is 0, the fault injection processing handler does not inject a fault into a fault injection target function. - When the caller address is effective, the fault injection processing handler of the
fault injection executor 120 determines whether the caller address is included in the execution address of a module registered as a test target, i.e., the address of a memory in which the module registered as the test target is executed, on the basis of the effectiveness check information of the module registered as the test target in operation S273. - When the caller address is not included in the execution address of the module registered as the test target in operation S273, the fault injection processing handler of the
fault injection executor 120 returns to operation S271 of obtaining the fore caller address. This return operation is repeated until a caller address is not effective or the caller address is included in the execution address of atest target module 150. - When the caller address is included in the execution address of the
test target module 150 in operation S273, the fault injection processing handler of thefault injection executor 120 checks whether the fault injection condition set by a user is satisfied in operation S274. - When the fault injection condition is not satisfied in operation S274, the fault injection processing handler of the
fault injection executor 120 designates a fault injection activation flag as 0 based on the result value of the effectiveness check and is ended in operation S276. - However, when the fault injection condition is completely satisfied, the fault injection processing handler of the
fault injection executor 120 designates a fault injection activation flag as 1 based on the result value of the effectiveness check and is ended in operation S275. When the flag is 1, the fault injection processing handler injects a fault into the fault injection target function. - As described above, the
fault injection executor 120 may inject a fault only into the location of a module that is selected as a test target among a plurality of modules sharing a specific function. Accordingly, it prevents the fault from being injected into an undesired location (for example, another module instead of a designated module), and the software reliability test is performed in a selected location efficiently. - A workload generation method for a software reliability test will be described with reference to
FIG. 4 .FIG. 4 is a flowchart illustrating a workload generation method in atest target module 150 for a software reliability test according to an exemplary embodiment. - Referring to
FIG. 4 , theworkload generation unit 130 receives workload generation information that is analyzed on the basis of a fault type and a designated module in operation S300. - For example, the
workload generation unit 130 may receive the workload generation information inputted from a user, through thefault injection unit 110, or may directly receive workload generation information from the user. - Herein, the workload generation information may include a designated module and its fault injection location information.
- The
workload generation unit 130 generates a workload in atarget module 150 based on the received workload generation information. - For example, the
workload generation unit 130 composes a workload generation scenario for a workload to be generated on the basis of the workload generation information in operation S310. In the composed workload generation scenario, the workload may be intensively generated in order for a function corresponding to a fault injection location to be executed in operation S320. - Herein, the workload generation is for executing a function (for example, a fault injection target function) corresponding to the fault injection location of a
target module 150 through the operation of the a designated module, and theworkload generation unit 130 may replace the role of an application program in a scheme similar to a scheme of requesting the performance of a function to atarget module 150 in the application program. - Intensive workload generation may increase the frequency of requesting the execution of the function to the
target module 150 than the frequency of requesting under a normal operation instead of a software test. For example, if the request is performed once under the normal operation, the request may be performed a hundred times under the intensive workload generation. - A number of exemplary embodiments have been described above. Nevertheless, it will be understood that various modifications may be made. For example, suitable results may be achieved if the described techniques are performed in a different order and/or if components in a described system, architecture, device, or circuit are combined in a different manner and/or replaced or supplemented by other components or their equivalents. Accordingly, other implementations are within the scope of the following claims.
Claims (16)
1. A software reliability test method using selective fault activation, comprising:
registering a test target module; and
injecting a fault into a fault injection target function when a caller of the fault injection target function is comprised in the registered module.
2. The software reliability test method of claim 1 , wherein the registering comprises:
receiving information related to fault injection comprising information of the module;
checking whether the module exists in a kernel on the basis of the received information; and
registering the module as a test target, when the module exists in the kernel.
3. The software reliability test method of claim 1 , wherein the injecting of a fault comprises:
collecting effectiveness check information comprising an address of a memory in which the module is executed;
determining whether a caller of the fault injection target function is comprised in the module on the basis the collected effectiveness check information; and
injecting a fault into the fault injection target function, when the caller is comprised in the module.
4. The software reliability test method of claim 3 , wherein the determining comprises:
determining whether an address of the caller is comprised in the address area of the memory in which the module is executed; and
determining as that the caller is comprised in the module, when the address of the caller is comprised in the address of the memory.
5. The software reliability test method of claim 3 , further comprising registering a fault injection processing handler for processing the fault injection target function,
wherein the injecting of a fault comprises injecting the fault into the fault injection target function through the fault injection processing handler.
6. The software reliability test method of claim 1 , further comprising generating a workload for the module to call the fault injection target function,
wherein the injecting of a fault comprises injecting the fault into the fault injection target function according to the generated workload.
7. A test area restriction method, comprising:
collecting effectiveness check information comprising an address of a memory in which a module registered as a test target among a plurality of modules sharing a specific function is executed;
determining whether a caller of a fault injection target function comprised in the specific function is comprised in the registered module on the basis of the collected effectiveness check information; and
injecting a fault into the fault injection target function, when the caller is comprised in the registered module.
8. The test area restriction method of claim 7 , wherein the determining comprises:
determining whether a caller address of the fault injection target function is comprised in the address of the memory in which the registered module is executed; and
determining as that the caller is comprised in the registered module, when the caller address is comprised in the address of the memory.
9. A workload generation method for testing software reliability, comprising:
receiving workload information corresponding to a module which is registered as a test target among a plurality of modules sharing a specific function; and
generating a workload in the registered module on the basis of the received workload information.
10. The workload generation method of claim 9 , wherein the generating of a workload comprises generating the workload for the registered module to call a fault injection target function of the specific function.
11. A computing apparatus, comprising:
a plurality of modules operating in a kernel; and
a fault injection executor existing in the kernel, registering a designated module among the modules as a test target module, and injecting a fault into a fault injection target function when the fault injection target function is called by the registered module.
12. The computing apparatus of claim 11 , wherein the fault injection executor receives information related to fault injection comprising information of the designated module to check whether the designated module exists in the kernel, and registers the designated module as the test target when the designated module exists in the kernel.
13. The computing apparatus of claim 11 , wherein:
the fault injection executor collects effectiveness check information comprising an address area of a memory in which the registered module is executed, and
the fault injection executor determines whether a caller of the fault injection target function is comprised in the registered module on the basis of the collected effectiveness check information, and injects a fault into the called fault injection target function when the caller is comprised in the registered module.
14. The computing apparatus of claim 13 , wherein the fault injection executor determines whether an address of the caller is comprised in the address of the memory in which the registered module is executed, and injects a fault into the called fault injection target function when the address of the caller is comprised in the address of the memory.
15. The computing apparatus of claim 11 , wherein the fault injection executor registers a fault injection processing handler in the fault injection target function, and injects a fault into the fault injection target function through the fault injection processing handler.
16. The computing apparatus of claim 11 , further comprising a workload generating unit generating a workload for the registered module to call the fault injection target function of the specific function,
wherein the fault injection executor injects the fault into the called fault injection target function according to the generated workload.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020090040283A KR101266359B1 (en) | 2009-05-08 | 2009-05-08 | Method for software reliability testing using selective fault activation, method for test area restricting, method for workload generating and computing apparatus for software reliability testing thereof |
KR10-2009-0040283 | 2009-05-08 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100287412A1 true US20100287412A1 (en) | 2010-11-11 |
US8418143B2 US8418143B2 (en) | 2013-04-09 |
Family
ID=43063078
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/572,939 Expired - Fee Related US8418143B2 (en) | 2009-05-08 | 2009-10-02 | Software reliability test method using selective fault activation, test area restriction method, workload generation method and computing apparatus for testing software reliability using the same |
Country Status (2)
Country | Link |
---|---|
US (1) | US8418143B2 (en) |
KR (1) | KR101266359B1 (en) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120054532A1 (en) * | 2010-08-24 | 2012-03-01 | Red Hat, Inc. | Dynamic fault configuration using a registered list of controllers |
US20130031533A1 (en) * | 2010-04-13 | 2013-01-31 | Nec Corporation | System reliability evaluation device |
US20130042152A1 (en) * | 2011-08-09 | 2013-02-14 | Lukás Fryc | Declarative testing using dependency injection |
US20130055027A1 (en) * | 2011-08-25 | 2013-02-28 | Electronics And Telecommunications Research Institute | Low cost error-based program testing apparatus and method |
CN103164323A (en) * | 2011-12-09 | 2013-06-19 | 深圳市腾讯计算机系统有限公司 | Data automatic generation method and data automatic generation system |
CN103617121A (en) * | 2013-12-09 | 2014-03-05 | 北京京航计算通讯研究所 | Method for building AD/DA interface fault model on basis of NI platform |
CN103617114A (en) * | 2013-10-23 | 2014-03-05 | 江苏大学 | Third-party component vulnerability test method based on conditions and parameter variations |
US8954807B2 (en) | 2012-07-05 | 2015-02-10 | Electronics & Telecommunications Research Institute | Fault-based software testing method and system |
CN104679636A (en) * | 2013-11-28 | 2015-06-03 | 中国移动通信集团公司 | System reliability test method and device |
US20150212923A1 (en) * | 2014-01-28 | 2015-07-30 | Kabushiki Kaisha Toshiba | Nontransitory processor readable recording medium having fault injection program recorded therein and fault injection method |
CN104978260A (en) * | 2014-04-01 | 2015-10-14 | 腾讯科技(深圳)有限公司 | Software test method and device |
US9189370B2 (en) | 2013-05-23 | 2015-11-17 | Electronics And Telecommunications Research Institute | Smart terminal fuzzing apparatus and method using multi-node structure |
US9842045B2 (en) * | 2016-02-19 | 2017-12-12 | International Business Machines Corporation | Failure recovery testing framework for microservice-based applications |
CN109117371A (en) * | 2018-08-08 | 2019-01-01 | 中国航空工业集团公司雷华电子技术研究所 | A kind of fault filling method improving period BIT verifying ability |
US10235278B2 (en) | 2013-03-07 | 2019-03-19 | International Business Machines Corporation | Software testing using statistical error injection |
US10261891B2 (en) | 2016-08-05 | 2019-04-16 | International Business Machines Corporation | Automated test input generation for integration testing of microservice-based web applications |
CN109857522A (en) * | 2019-03-01 | 2019-06-07 | 哈尔滨工业大学 | A kind of virtualization layer fault filling method towards KVM |
CN109857582A (en) * | 2019-01-29 | 2019-06-07 | 山西大学 | A kind of open source software Reliability Modeling for introducing failure based on misarrangement process |
CN110188012A (en) * | 2019-04-26 | 2019-08-30 | 华中科技大学 | A kind of FPGA register stage single-particle inversion failure simulation method and system |
US20220100645A1 (en) * | 2020-09-29 | 2022-03-31 | Amazon Technologies, Inc. | Automated testing of systems and applications |
CN115729724A (en) * | 2022-11-30 | 2023-03-03 | 中电金信软件有限公司 | Fault injection method, fault test system, electronic device and readable storage medium |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104915192B (en) * | 2015-03-25 | 2018-07-10 | 哈尔滨工程大学 | A kind of Software Reliability Modeling method based on transfer point and imperfect misarrangement |
KR102126960B1 (en) | 2020-04-24 | 2020-06-25 | 한화시스템 주식회사 | Reliability testing integrated-platform of weapon system software for next-generation naval ship |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060126799A1 (en) * | 2004-12-15 | 2006-06-15 | Microsoft Corporation | Fault injection |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4189854B2 (en) * | 2003-07-28 | 2008-12-03 | 新日鉄ソリューションズ株式会社 | Failure verification operation apparatus and failure verification method |
KR100897412B1 (en) | 2006-11-09 | 2009-05-14 | 한국전자통신연구원 | Automatic software testing system and method using faulted file |
-
2009
- 2009-05-08 KR KR1020090040283A patent/KR101266359B1/en not_active IP Right Cessation
- 2009-10-02 US US12/572,939 patent/US8418143B2/en not_active Expired - Fee Related
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060126799A1 (en) * | 2004-12-15 | 2006-06-15 | Microsoft Corporation | Fault injection |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130031533A1 (en) * | 2010-04-13 | 2013-01-31 | Nec Corporation | System reliability evaluation device |
US9015675B2 (en) * | 2010-04-13 | 2015-04-21 | Nec Corporation | System reliability evaluation device |
US20120054532A1 (en) * | 2010-08-24 | 2012-03-01 | Red Hat, Inc. | Dynamic fault configuration using a registered list of controllers |
US9652365B2 (en) * | 2010-08-24 | 2017-05-16 | Red Hat, Inc. | Fault configuration using a registered list of controllers |
US20130042152A1 (en) * | 2011-08-09 | 2013-02-14 | Lukás Fryc | Declarative testing using dependency injection |
US9208064B2 (en) * | 2011-08-09 | 2015-12-08 | Red Hat, Inc. | Declarative testing using dependency injection |
US8886999B2 (en) * | 2011-08-25 | 2014-11-11 | Electronics And Telecommunications Research Institute | Low cost error-based program testing apparatus and method |
US20130055027A1 (en) * | 2011-08-25 | 2013-02-28 | Electronics And Telecommunications Research Institute | Low cost error-based program testing apparatus and method |
CN103164323A (en) * | 2011-12-09 | 2013-06-19 | 深圳市腾讯计算机系统有限公司 | Data automatic generation method and data automatic generation system |
US8954807B2 (en) | 2012-07-05 | 2015-02-10 | Electronics & Telecommunications Research Institute | Fault-based software testing method and system |
US10235278B2 (en) | 2013-03-07 | 2019-03-19 | International Business Machines Corporation | Software testing using statistical error injection |
US9189370B2 (en) | 2013-05-23 | 2015-11-17 | Electronics And Telecommunications Research Institute | Smart terminal fuzzing apparatus and method using multi-node structure |
CN103617114A (en) * | 2013-10-23 | 2014-03-05 | 江苏大学 | Third-party component vulnerability test method based on conditions and parameter variations |
CN104679636A (en) * | 2013-11-28 | 2015-06-03 | 中国移动通信集团公司 | System reliability test method and device |
CN103617121A (en) * | 2013-12-09 | 2014-03-05 | 北京京航计算通讯研究所 | Method for building AD/DA interface fault model on basis of NI platform |
US20150212923A1 (en) * | 2014-01-28 | 2015-07-30 | Kabushiki Kaisha Toshiba | Nontransitory processor readable recording medium having fault injection program recorded therein and fault injection method |
CN104978260A (en) * | 2014-04-01 | 2015-10-14 | 腾讯科技(深圳)有限公司 | Software test method and device |
US9842045B2 (en) * | 2016-02-19 | 2017-12-12 | International Business Machines Corporation | Failure recovery testing framework for microservice-based applications |
US10489279B2 (en) | 2016-08-05 | 2019-11-26 | International Business Machines Corporation | Automated test input generation for integration testing of microservice-based web applications |
US10261891B2 (en) | 2016-08-05 | 2019-04-16 | International Business Machines Corporation | Automated test input generation for integration testing of microservice-based web applications |
US11640350B2 (en) | 2016-08-05 | 2023-05-02 | International Business Machines Corporation | Automated test input generation for integration testing of microservice-based web applications |
US11138096B2 (en) | 2016-08-05 | 2021-10-05 | International Business Machines Corporation | Automated test input generation for integration testing of microservice-based web applications |
CN109117371A (en) * | 2018-08-08 | 2019-01-01 | 中国航空工业集团公司雷华电子技术研究所 | A kind of fault filling method improving period BIT verifying ability |
CN109857582A (en) * | 2019-01-29 | 2019-06-07 | 山西大学 | A kind of open source software Reliability Modeling for introducing failure based on misarrangement process |
CN109857522A (en) * | 2019-03-01 | 2019-06-07 | 哈尔滨工业大学 | A kind of virtualization layer fault filling method towards KVM |
CN110188012A (en) * | 2019-04-26 | 2019-08-30 | 华中科技大学 | A kind of FPGA register stage single-particle inversion failure simulation method and system |
US20220100645A1 (en) * | 2020-09-29 | 2022-03-31 | Amazon Technologies, Inc. | Automated testing of systems and applications |
US11983100B2 (en) * | 2020-09-29 | 2024-05-14 | Amazon Technologies, Inc. | Automated testing of systems and applications |
CN115729724A (en) * | 2022-11-30 | 2023-03-03 | 中电金信软件有限公司 | Fault injection method, fault test system, electronic device and readable storage medium |
Also Published As
Publication number | Publication date |
---|---|
KR20100121225A (en) | 2010-11-17 |
US8418143B2 (en) | 2013-04-09 |
KR101266359B1 (en) | 2013-05-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8418143B2 (en) | Software reliability test method using selective fault activation, test area restriction method, workload generation method and computing apparatus for testing software reliability using the same | |
Krammer et al. | MARMOT: An MPI analysis and checking tool | |
US7950001B2 (en) | Method and apparatus for instrumentation in a multiprocessing environment | |
US7316005B2 (en) | Data race detection using sequential program analysis | |
US8756572B2 (en) | Debugger-set identifying breakpoints after coroutine yield points | |
US10303490B2 (en) | Apparatus and method for optimizing startup of embedded system | |
CN102063286B (en) | Program flow controls | |
US7523446B2 (en) | User-space return probes | |
US20080263342A1 (en) | Apparatus and method for handling exception signals in a computing system | |
CN101482845B (en) | Method and system for calling instant debugger | |
US9424004B2 (en) | Execution guards in dynamic programming | |
JP6401235B2 (en) | Operating system support for contracts | |
US9639451B2 (en) | Debugger system, method and computer program product for utilizing hardware breakpoints for debugging instructions | |
US20160188441A1 (en) | Testing multi-threaded applications | |
Artho et al. | JNuke: Efficient dynamic analysis for Java | |
Lettner et al. | PartiSan: fast and flexible sanitization via run-time partitioning | |
US20080127118A1 (en) | Method and system for dynamic patching of software | |
CN111897711A (en) | Method and device for positioning bug in code, electronic equipment and readable storage medium | |
US20070174703A1 (en) | Method for enhancing debugger performance of hardware assisted breakpoints | |
CN115686676B (en) | Dynamic calling method and device for object and electronic equipment | |
Borchert | Reducing the Resource Consumption of a Fault-Tolerant Operating System by Static Analysis | |
JP2009223841A (en) | Instruction log acquisition program and virtual machine system | |
Arena et al. | A Case Study in Obtaining Freedom from Interference in a Mixed-ASIL Architecture | |
CN116962017A (en) | Windows system callback detection method and system based on PIN instrumentation | |
Wagle et al. | Want Predictable GPU Execution? Beware SMIs! |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ELECTRONICS AND TELECOMMUNICATIONS RESEARCH INSTIT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHA, GYU IL;KIM, YOUNG HO;JUNG, SUNG IN;REEL/FRAME:023322/0520 Effective date: 20090915 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20170409 |