JP2014206807A - Software inspection method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To inspect software targeting a state of a memory, a child process or a thread by a process when the software is executed.SOLUTION: A software inspection method of an inspection device that inspects software using a scenario in which a predetermined state of a process and a corresponding operation when the software is executed are described includes: a monitoring step in which a dynamic tracker of the inspection device monitors a memory, a child process, or a thread by a process to be inspected; an instruction step in which an inspection unit of the inspection device instructs the dynamic tracker to operate based upon the information on the memory, child process, or thread monitored by the dynamic tracker and the scenario; and a control step in which the dynamic tracker controls the process to be inspected as instructed by the inspection unit.

Description

  The present invention relates to a software inspection method and program. In particular, the present invention relates to a software inspection technique that enables execution of tests and debugs based on internal states of a plurality of processes even in a distributed system environment in which a plurality of processes are executed on a plurality of machines.

  When debugging a distributed system that implements a complex protocol, a formal model of the distributed system is created using a model description language, and a model checker is used to check whether the protocol satisfies the required properties. The method is widely adopted (see Non-Patent Document 1).

  In this method, a state transition machine model in which the state transition of each node of the distributed system is formally described is created, and the entire distributed system is defined as a direct product of the state transition machine. For a state machine defined in this way, it follows all possible transitions and checks that the protocol is free of bugs by checking that the given properties are satisfied for each state. .

  The above method is excellent in that the time cost required for conducting a comprehensive inspection is relatively small, but there is a technique for mechanically confirming that there is no discrepancy between the created model and the implementation. Has the disadvantage of not. For this reason, there is a model checking technique in which the inspection target is the mounting itself (see Non-Patent Document 2).

  The technique introduced in Non-Patent Document 2 is intended for applications that run on Windows (registered trademark), and notifies the tester of state updates when the Win32 API is called. Upon receiving the status update notification, the tester determines whether or not to fail the Win32 API call and sends an instruction to the process to be tested.

Gerard J. Holzmann. The Model Checker SPIN. Journal: IEEE Transactions on Software Engineering, vol. 23, no. 5, pp. 279-295, 1997. Junfeng Yang, Tisheng Chen, Ming Wu, Zhilei Xu, Xuezheng Liu, Haoxiang Lin, Mao Yang, Fan Long, Lintao Zhang, Lidong Zhou.MODIST: Transparent Model Checking of Unmodified Distributed Systems.In proceedings of the Networked Systems Design and Implementation- NSDI, pp. 213-228, 2009.

  The technology introduced in Non-Patent Document 2 makes it possible to perform a comprehensive inspection with the implementation as the inspection target, but the OS (Operating System) system call is issued when the status update is notified to the tester. Limited to calls. For this reason, there is a problem that fault injection cannot be performed in response to a change in the state of the process memory.

  An object of the present invention is to inspect software for a state of a memory, a child process, or a thread by a process when the software is executed.

A software inspection method according to an aspect of the present invention includes:
A software inspection method in an inspection apparatus for inspecting software using a scenario describing a predetermined state and a corresponding operation in a process when software is executed,
A monitoring step in which a dynamic tracker of the inspection device monitors a memory, a child process or a thread by a process to be inspected;
An instructing step for instructing the dynamic tracker to perform an operation based on memory and child process or thread information and scenarios monitored by the dynamic tracker;
A control step in which the dynamic tracker controls a process to be inspected based on an instruction from the inspector;
It is characterized by having.

A program according to an aspect of the present invention is
A program that causes a computer to function as an inspection device that inspects software using a scenario that describes a predetermined state and a corresponding operation in the process when the software is executed. The computer depends on the process to be inspected. Dynamic tracking means for monitoring a memory, a child process or a thread, and instructing the dynamic tracking means to perform an operation based on information and a scenario of the memory, child process or thread monitored by the dynamic tracking means. Inspection means,
Function as
The dynamic tracking unit controls a process to be inspected based on an instruction from the inspection unit.

  According to the embodiment of the present invention, it is possible to inspect the software for the state of a memory, a child process, or a thread by a process when the software is executed.

The block diagram of the software inspection apparatus which concerns on the Example of this invention. The flowchart of the dynamic tracker in the software test | inspection apparatus based on the Example of this invention. The flowchart of the test | inspector in the software test | inspection apparatus based on the Example of this invention. Example when inspecting a plurality of processes in a software inspection apparatus according to an embodiment of the present invention

  Examples of the present invention will be described in detail below.

  In the embodiment of the present invention, a software inspection apparatus that inspects software using a scenario describing a predetermined state and a corresponding operation in a process when the software is executed will be described. Typically, a software inspection device is a computer that processes data according to a program loaded in a storage device.

  FIG. 1 shows a block diagram of a software inspection apparatus according to an embodiment of the present invention. The software inspection device includes a scenario storage unit 101, a dynamic tracker 103, and an inspection device 105.

  The scenario storage unit 101 is a storage device that stores a symbol table that stores address information of variables in a memory and a scenario that describes a predetermined state and a corresponding operation in a process when software is executed. The symbol table is a table that defines address information on a memory to which global variables of a process to be inspected are assigned and address information on a memory secured at the time of execution. Such address information is acquired from, for example, a debugging format called DWARF. The scenario is a combination of operations given to the inspector 105 described by the user. For example, the operation described by the scenario includes causing an operation such as fault injection or confirmation of assertion to be performed when the process enters a specific state.

  The dynamic tracker 103 monitors a memory, a child process, or a thread by a process to be inspected. For example, in the dynamic tracker 103, a change corresponding to one of (1) a change in the state of the memory, (2) allocation and release of the memory, and (3) creation and termination of the child process or thread has occurred. In this case, the tester 105 is notified.

  The tester 105 instructs the dynamic tracker 103 to operate based on the memory, child process or thread information monitored by the dynamic tracker 103 and the scenario. For example, when the memory, child process, or thread information notified from the dynamic tracker 103 satisfies a predetermined state described in the scenario, the tester 105 performs fault injection or assertion on the dynamic tracker 103. Instruct the operation like confirmation. The dynamic tracker 103 controls a process to be inspected based on an instruction from the inspector 105.

  Details of the operation of the software inspection apparatus will be described below.

<Operation of dynamic tracker>
FIG. 2 shows a flowchart of the dynamic tracker 103 in the software inspection apparatus according to the embodiment of the present invention.

  The dynamic tracker 103 executes an instruction indicated by the program counter until any of the following events occurs in the process to be inspected (step S101). Then, when any of the following events occurs, the information is notified to the tester 105. The following events are also called traps because the program is interrupted when these events occur. The occurrence of an event is captured using a program dynamic tracking tool (eg DynamoRIO).

  Events captured by the dynamic tracker 103 include (1) state change on the memory, (2) memory allocation and release, and (3) child process or thread creation and termination.

(1) Changes in the state on the memory In the embodiment of the present invention, the states that can be implemented by the software are defined as a memory region that is used as a global variable of a process in which the software is executed, and a memory region that is secured at the time of execution. It is defined as the state of. When the dynamic tracker 103 deletes the right to write the page including the global variable of the process to be inspected and the page including the memory allocated at the time of execution, and writing to the page occurs Is set to be called to signal the segmentation violation. The page to which the global variable is assigned and the page including the memory secured at the time of execution are acquired from the address information defined in the symbol table of the scenario storage unit 101.

  The dynamic tracker 103 determines whether a segmentation violation has occurred (step S103). If a segmentation violation has occurred (step S103: Yes), the dynamic tracker 103 determines that a change in the state on the memory has occurred. When the process to be inspected does not access the page for which writing has been prohibited (step S105: No), the dynamic tracker 103 determines that the bug is a software bug and ends the process (step S107). When the process to be monitored is accessing a page for which writing is prohibited (step S105: Yes), the dynamic tracker 103 reads the address on the memory in which writing is attempted within the signal handler and the written value. And the size of the written value is obtained by decoding the instruction pointed to by the program counter that caused the segmentation violation (step S109).

  The dynamic tracker 103 configures the obtained address on the memory, the written value, and the size of the written value as a message to be described later, and transmits the message to the inspector 105 operating as another process. (Step S111). The tester 105 updates the state of the process of the entire system that is held based on the sent information. As will be described later, the tester 105 sends back a value representing an instruction to the dynamic tracker 103 based on the state of the process of the entire system, so that the dynamic tracker 103 returns data returned from the tester 105. Wait for.

Here, the specific message configuration notified to the inspector 105 includes the following three sets:
(Pointer type: address in memory where update was performed, integer type: written value, integer type: number of bytes of written value)
(2) Securing and releasing memory The dynamic tracker 103 is a function for securing or releasing memory provided by the library and a system that calls them internally in order to track the state of the memory secured on the heap. It is necessary to notify the tester 105 of a call.

  If no segmentation violation has occurred in step S103 (step S103: No), the dynamic tracker 103 determines that memory allocation or release, child process or thread generation or termination has occurred. Among these, the securing or releasing of the memory will be described below.

When the memory is secured or released, the dynamic tracker 103 notifies the tester 105 of the memory secured or released (step S113). A specific message configuration notified to the inspector 105 is as follows:
For memory allocation: (Pointer type: assigned start address, integer type: number of bytes in the allocated area)
When releasing memory: (Pointer type: First address to be released)
As will be described later, the tester 105 sends back a value representing an instruction to the dynamic tracker 103 based on the state of the process of the entire system, so that the dynamic tracker 103 returns data returned from the tester 105. (Step S115).

(3) Creation and Termination of Child Process or Thread When the process to be inspected creates or terminates a new child process or thread, the dynamic tracker 103 notifies the inspector 105 of the event (step S113). This event needs to be tracked for processing performed by a child process or thread, or for tracking a memory area reserved for each thread. When creating a child process, the specific message configuration notified to the tester is as follows: (integer type: process ID of the new process)
For child process termination: (Integer type: Process ID of the terminated process)
When creating a thread: (Integer type: Thread ID of the new thread)
For thread termination: (Integer type: thread ID of terminated thread)
The inspector 105 updates the state of the process to be inspected internally stored in response to the above three events captured by the dynamic tracker 103. Then, based on the state of the process to be inspected, a scenario given by the user described later is executed.

The process to be inspected operates based on the value returned from the inspector 105 via the dynamic tracker 103. Do not proceed until the instruction is returned. There are the following three types of combinations of instructions and operations to be executed in response to the instructions.
(1) [Instruction] Do nothing: [Action] Proceed with processing (2) [Instruction] Generate a network error: [Action] Discard all TCP (Transmission Control Protocol) connections created by the process ( 3) [Instruction] Cause disk error: [Action] Close all open files in process and delete all files created by that process Then, the value of the saved program counter is added by the size of the instruction that caused the segmentation violation, and execution of the next instruction is resumed.

  Among the combinations of the above three types of instructions and operations, when the inspector 105 instructs to execute the next instruction without doing anything (step S117: Yes), that is, among the above instructions (1 ) Is instructed, the dynamic tracker 103 executes the instruction indicated by the next program counter (step S101).

  On the other hand, when confirmation of fault injection or assertion is instructed from the inspector 105 (step S117: No), the dynamic tracker 103 confirms fault injection or assertion (step S119). Fault injection means that an error is intentionally generated to check for error handling errors. For example, fault injection corresponds to (2) and (3) among the above instructions. Assertion means a function that generates an error, an exception, a message display, a process interruption, or the like when a requirement to be satisfied described as a system premise is not satisfied at the time of execution. In order to perform inspection by fault injection or assertion, the dynamic tracker 103 executes an instruction pointed to by the next program counter (step S101).

<Operation of inspection device>
FIG. 3 shows a flowchart of the inspector 105 in the software inspection apparatus according to the embodiment of the present invention.

  The inspector 105 operates based on the event notified from the process to be inspected. For this reason, the inspector 105 waits until it receives from the dynamic tracker 103 the start of a new process to be inspected or the update of the state of the process under inspection (step S201). If it is the start of a new process to be inspected (step S203: Yes), data for expressing the new process is secured and initialized (step S205). If it is not the start of a new inspection target process (step S203: No), the inspector 105 updates the state of the corresponding process.

The scenario given to the tester 105 is described as a repetition of a combination of the following state and the operation of the tester 105 corresponding to the following state, and is stored in the scenario storage unit 101:
(Process 1 status, Process 2 status, ..., Process n status)-> Inspector operation The status saved for each process is the first created parent process and all child processes. All global variables, the dynamically used memory usage status, the number of threads, and the memory area reserved for each thread. For convenience, the state of this process is called the target state.

  The target state is described as a condition defined on top of the stored process state. For example, the target state is described as the state of a process that satisfies a predetermined condition.

  As described above, the tester 105 updates the state of each process based on the event notified from each process. When the state of each process coincides with the target state (step S209: Yes), the tester 105 performs the operation described on the right side of the arrow in the description example of the scenario (step S211). Examples of the operation of the inspector 105 include fault injection, confirmation of assertion with respect to the state of the entire distributed system, or a combination thereof. When the state of each process does not match the target state (step S209: No), the inspector 105 receives from the dynamic tracker 103 the start of a new process to be inspected or the update of the state of the process being inspected. (Step S201).

In order to facilitate the description of the scenario by the user, two special notations are prepared as the state of each process.
Wild card: Allow any state. Even if a status update notification occurs, the process is not stopped.
Unconditional stop: If the state of the nth process k is an unconditional stop after the operation of the n-1st tester is finished, the process k is not allowed to update the state.

  Using these notations, the user can describe a sequence of state transitions to be examined as an individual scenario. In addition to the initial state and end state of each process, the user describes the transitions between them, and by creating a composite of them, it is possible to generate all the scenarios to be examined.

  When the inspector 105 does not achieve all the target states, that is, when all the scenarios are not completed (step S213: No), the inspector 105 starts or inspects a new process to be inspected. The process waits until an update of the process state is received from the dynamic tracker 103 (step S201). When all the target states are achieved, that is, when all the scenarios are completed (step S213: Yes), the inspector 105 ends the process.

<Example when inspecting multiple processes>
FIG. 4 shows an example when a plurality of processes are inspected in the software inspection apparatus according to the embodiment of the present invention. FIG. 4 shows a state where the dynamic tracker 103 tracks the states s1 to sn of the processes 1 to n to be inspected and notifies the inspector 105 of them.

  As an example, a scenario for checking whether or not a disk error can be correctly processed in a distributed storage system will be described. In this distributed storage system, data is stored in units of objects, and redundancy can be set at the time of storage. It is assumed that this distributed storage system is operated by four computers and the redundancy is set to 3 (n = 4 in FIG. 4). That is, when one object is stored, the object is stored in three of the four computers. If the computer used by the operating system fails and the operation cannot be continued, the object saved by that computer is restored from another computer to restore redundancy. Repair work shall be performed. Then, when only a number of computers that cannot satisfy the set redundancy can be used, a behavior of rejecting all write requests from the user is performed.

  This system process is assumed to have a boolean global variable called running set to true after initialization is complete. It is also assumed that a pointer type variable called recovery_work is set to non-null during repair work, and becomes null after completion.

The scenario to be checked is that when this system uses four computers, when one computer fails first and another computer that detects it starts repair work, another computer In the case of a failure, the content is to check whether a write request is accepted. In this case, the scenario is described as follows:
(proc0: running == true, proc1: running == true, proc2: running == true, proc3: running == true)-> kill proc3
(proc0: recovery_work! = NULL, proc1: recovery_work! = NULL, proc3, recover_work! = NULL)-> kill proc3, assert (DENIED == write object proc0)
If you want to perform an exhaustive inspection, this scenario can be covered by covering all 4 * 3 * 2 = 24 processes of the process that is forcibly terminated first, the process that is forcibly terminated, and the process for which writing is attempted. Can be inspected.

  Using this scenario, as described with reference to FIG. 1, the dynamic tracker 103 uses the statuses s1 to s1 of the memories, child processes, and threads by the monitored processes 1 to n (proc0 to proc3 in the above scenario). sn (the value of the global variable called running in the above scenario) is monitored, and the state transition is notified to the tester 105 synchronously. The dynamic tracker 103 performs an operation according to a reply to the state notified to the inspector 105.

  The inspector 105 updates the state set (s1,... Sn) notified from the dynamic tracker 103, and based on the file describing the scenario given at the time of initialization, the inspecting process 1 Controls the progress of ~ n (proc0 ~ proc3 in the above scenario).

<Effect of the embodiment of the present invention>
In the technology introduced in Non-Patent Document 2, only the call of a system call is notified to the tester as an event. In this method, in order to obtain the memory state in the program, it is necessary to estimate the memory state from the call history of system calls. Moreover, since it is a state obtained by estimation, the possibility of deviation from the actual state always remains.

  In the embodiment of the present invention, it is possible to reliably make a copy of the state on the memory. Therefore, when describing a scenario as a condition for a target state, it is possible to describe a variable of a process to be inspected as a term. For this reason, in the embodiment of the present invention, it is possible to provide the same convenience for debugging a distributed system as the assertion that can be used when debugging a single system.

  According to the embodiment of the present invention, it is possible to execute a highly accurate inspection effectively by enabling a comprehensive inspection corresponding to a change in the memory state of a process for installed software. . In addition, when executing operations with the tester, the user can efficiently generate all scenarios that the user wants to inspect, and not only the initial state and end state of each process but also the sequence of state transitions to be inspected. It is possible to describe as individual scenarios including transitions, and the scenario generation efficiency is improved.

  Further, according to the embodiment of the present invention, it is possible to provide the same convenience as the assertion used when debugging a non-distributed system for debugging the distributed system.

101 scenario storage unit 103 dynamic tracker 105 tester

Claims (6)

A software inspection method in an inspection apparatus for inspecting software using a scenario describing a predetermined state and a corresponding operation in a process when software is executed,
A monitoring step in which a dynamic tracker of the inspection device monitors a memory, a child process or a thread by a process to be inspected;
An instructing step for instructing the dynamic tracker to perform an operation based on memory and child process or thread information and scenarios monitored by the dynamic tracker;
A control step in which the dynamic tracker controls a process to be inspected based on an instruction from the inspector;
A software inspection method.   In the monitoring step, the dynamic tracker deletes the right to write the page on the memory to which the global variable of the process to be inspected is allocated and the page on the memory secured at the time of execution, thereby deleting the memory on the memory. The software inspection method according to claim 1, wherein a change in the state of the software is monitored.   The software monitoring method according to claim 1, wherein in the monitoring step, the dynamic tracker monitors whether a memory to be allocated and released by a process to be inspected.   4. The software inspection method according to claim 1, wherein in the monitoring step, the dynamic tracker monitors generation and termination of a child process or a thread by a process to be inspected. 5.   When the memory, child process, or thread information monitored by the dynamic tracker satisfies a predetermined state described in a scenario, the instruction step confirms fault injection or assertion for the dynamic tracker. The software inspection method according to claim 1, wherein the software inspection method is instructed. A program that causes a computer to function as an inspection device that inspects software using a scenario that describes a predetermined state and a corresponding operation in the process when the software is executed. The computer depends on the process to be inspected. Dynamic tracking means for monitoring a memory, a child process or a thread, and instructing the dynamic tracking means to perform an operation based on information and a scenario of the memory, child process or thread monitored by the dynamic tracking means. Inspection means,
Function as
The dynamic tracking unit is a program for controlling a process to be inspected based on an instruction from the inspection unit.

Images