Information processing apparatus, process verification support method, and computer product

An information processing apparatus includes a detecting unit configured to detect an abort signal among signals from a kernel that monitors execution of a process by referring to details concerning the execution; an obtaining unit configured to obtain information that concerns the details concerning the execution of the process and is referred to by the kernel at a detection of the abort signal by the detecting unit; and a storing unit configured to store the information obtained by the obtaining unit into a memory.

FIELD

The embodiments discussed herein are related to the verification of details concerning the execution of a process that has been aborted (forcibly terminated).

BACKGROUND

Conventionally, an information processing apparatus has to be equipped with software including basic functions of an operating system (OS) such as a kernel, to execute an application prepared by a user (hereinafter, “user application”). The kernel includes various main functions such as monitoring user application(s) and/or peripheral devices, managing resources such as disks and memories, interrupt processing, inter-process communications, etc.

A group of given operations executed by the information processing apparatus described above is generally called a process, and several processes are executed in series or in parallel under the control of the kernel. During the execution of a process, the kernel continuously monitors details concerning the execution of the process and aborts the process if a given event such as an interrupt and an error occurs.

The abort is described with reference toFIGS. 10and11.FIG. 10is a flowchart of an abort signal transmission process executed by the kernel.FIG. 11is a flowchart of an abort signal reception process executed by the application.

As depicted in the flowchart ofFIG. 10, the kernel determines whether an event causing an abort has occurred (step S1001). The kernel awaits the occurrence of an event (step S1001: NO), and upon the occurrence of an event (step S1001: YES), executes an abort signal transmission process (step S1002). Then a signal transmission operation is executed (step S1003), and the operations of the kernel end.

The application, on the other hand, determines whether a signal from the kernel has been delivered (step S1101). The application awaits delivery of the signal (step S1101: NO). Upon delivery of the signal (step S1101: YES), a signal reception operation is executed (step S1102). Then, the application executes a reception process related to abort (step S1103). Through the procedure described above, the operations of the application end (see, for example, Japanese Patent No. 2836683).

As described inFIGS. 10 and 11, the abort signal is sent via the kernel. However, information concerning the sender of the signal (here, the kernel) is not communicated to the process of the recipient of the signal (here, the application). Furthermore, the executor of the process that has received the signal (here, the user of the information processing apparatus) does not have any means to search for the information concerning the sender of the received signal.

For example, in Solaris (a typical UNIX-like OS), information passed on to the signal reception operation during the signal transmission operation is limited to the following 4 items: (1) pointer information concerning the reception process; (2) pointer information concerning the receiving kernel thread; (3) information concerning the signal number; and (4) flag information indicating whether the source of the signal is the user or the kernel.

As a means to collect information concerning the sender of the signal, Solaris can be equipped with Audit (audit) and/or DTrace (dynamic trace) for use in the signal transmission operation (step S1003) described inFIG. 10. However, these two functions are set on the assumption that the same problem will occur again. Thus, if the problem does not reoccur, no information for investigation can be collected. Further, setting the functions requires some skill.

Furthermore, the impact of Audit and/or DTrace on system performance should be considered. In particular, Audit is likely to increase the load on the system since Audit obtains all information of a specified pointer. Furthermore, the information that can be collected by Audit and/or DTrace is for the entire system and for a system manager. Thus, even if a user executing the aborted process obtains the information, it is difficult for the user to investigate the cause of the abort. In other words, it is difficult for ordinary users to identify the cause of the abort.

Nonetheless, there are many cases in which a process is aborted due to reception of an unexpected signal, and thus the sender of the signal causing the abort needs to be investigated. However, the cause cannot be investigated due to the absence of the information concerning the sender of the signal. Currently, the user has no countermeasure other than setting Audit and waiting for a reoccurrence of the problem. As a result, in many cases the cause remains unidentified.

SUMMARY

According to an aspect of an embodiment, an information processing apparatus includes a detecting unit configured to detect an abort signal among signals from a kernel that monitors execution of a process by referring to details concerning the execution; an obtaining unit configured to obtain information that concerns the details concerning the execution of the process and is referred to by the kernel at a detection of the abort signal by the detecting unit; and a storing unit configured to store the information obtained by the obtaining unit into a memory.

DESCRIPTION OF EMBODIMENTS

FIG. 1is a schematic of an overview of process verification support according to the present embodiment.FIG. 1depicts an example of an execution of a process in an information processing apparatus100. The information processing apparatus100is equipped with a kernel110as software functioning as an OS controlling the entire apparatus, thereby enabling a user to execute an application via the information processing apparatus100. The kernel110controls the entire information processing apparatus100, and causes the information processing apparatus100to execute an application specified by the user, herein, a “user program120.”

InFIG. 1, it is assumed that the execution of a process is initiated at the user program120(step S121), and during the execution, an event causing an abort occurs (step S122). The kernel110continuously monitors the process under execution by the user program120and thus, can detect the occurrence of an event during execution of the process (step S122).

A detection of an occurrence of an event (step S122) triggers the kernel110to decide to abort the process (step S111), and to send an abort signal to the user program120(step S112).

Upon receiving the abort signal from the kernel110(step S123), the user program120aborts the process under execution (step S124). Although the operations described above are similarly executed by conventional kernels110and user programs120for aborts, in the present embodiment, further operations are executed after the abort of the process to support the user in verifying a process that has caused the abort.

After sending the abort signal at step S112, the kernel110stores signal sender information131into a memory130for storing information concerning signal transmission (signal sender information) (step S113). If verification of the process causing the abort is initiated by the user after the abort, the user program120refers to the signal sender information131stored into the memory130(step S125).

As described above, according to the information processing apparatus100of the present embodiment, even if a process is aborted during execution due to the reception of an unexpected abort signal, details concerning the execution of the process can be verified by referring to the signal sender information131stored into the memory130. Thus, the cause of the abort can be identified based on the result of the process verification.

A configuration of the information processing apparatus100enabling the identification of the cause of an abort, and operation thereof upon an abort, will be described.

FIG. 2is a diagram of a hardware configuration of the information processing apparatus according to the present embodiment.

As depicted inFIG. 2, the information processing apparatus200includes a computer210, input devices220, and output devices230, and may be connected to a network240, such as a local area network (LAN), a wide area network (WAN), and the Internet through a non-depicted router or a modem.

The computer210has a central processing unit (CPU), a memory, and an interface. The CPU governs overall control of the information processing apparatus200. The memory includes read-only memory (ROM), random access memory (RAM), a hard disk (HD), an optical disk211, and flash memory. The memory is used as a work area of the CPU.

The memory stores therein various programs, such as kernels and applications that are loaded in response to a command from the CPU. The reading and the writing of data with respect to the HD and the optical disk211are controlled by a disk drive. The optical disk211and the flash memory are removable from the computer210. The interface controls input from the input devices220, output to the output devices230, and transmission/reception with respect to the network240.

A keyboard221, a mouse222, and a scanner223are adopted as the input devices220. The keyboard221includes keys to input, for example, characters, numeric figures, and various kinds of instructions, and data is input through the keyboard221. The keyboard221may be a touch panel. The mouse222is used to move a cursor, select a range, move a window, or change window size. The scanner223optically reads an image as image data, which is stored in the memory of the computer210. The scanner223may have an optical character recognition (OCR) function.

A display231, a speaker232, a printer233, etc. are adopted as the output devices230. The display231displays a cursor, an icon, or a tool box as well as data, such as text, an image, and function information. The speaker232outputs sound, e.g., a sound effect or text-to-voice converted sound. The printer233prints image data or text data.

FIG. 3is a block diagram of a functional configuration of the information processing apparatus for the process verification support. As depicted inFIG. 3, the information processing apparatus200includes a detecting unit301, an obtaining unit302, a storing unit303, a memory304, an inquiring unit305, a retrieving unit306, an output unit307, and a generating unit308.

Each of the functions301to308may be included in a kernel310as an additional function thereof, or may be stored in the information processing apparatus200as an independent program and applied by the information processing apparatus200to software functioning as an OS. The functions can be implemented through an input and output I/F, and by causing the CPU to execute a program that is relevant to the functions301to308and stored in a storage device of the information processing apparatus200.

The detecting unit301detects an abort signal among signals from the kernel310that monitors the execution of a process by referring to details concerning the execution.

The obtaining unit302obtains information that concerns the details of the execution of a process320under execution and that is referred to by the kernel310at the detection of the abort signal by the detecting unit301. The obtained information on the details concerning the execution of the process320includes various types of information, such as the process number and the sender information. The obtaining unit302may obtain from the information on the details concerning the execution of the process320, given information specified in advance. By limiting the type(s) of information to be obtained, the load to the memory304can be reduced and information necessary for process verification can be efficiently obtained.

The storing unit303stores the information obtained by the obtaining unit302into the memory304that utilizes the storage device of the information processing apparatus200. The memory304may be a dedicated kernel memory that is generally provided in the storage device of the information processing apparatus200equipped with the kernel310.

The inquiring unit305receives an inquiry on the aborted process. The inquiry may be received directly (via the input device210depicted inFIG. 2) from the user executing the process320by the information processing apparatus200, or may be received from an application for verification of the aborted process executed by the information processing apparatus200.

The retrieving unit306retrieves, from the memory304, the information on the details concerning the execution of the process320for which the inquiry has been received by the inquiring unit305.

The output unit307outputs the information retrieved by the retrieving unit306. The output unit307may output the information stored in the memory304as it is, or may output the information after converting the information into a file of a given format. The output unit307may output the information retrieved by the retrieving unit306not only to the user of the information processing apparatus200, but also to a given address specified by the user, when the inquiring unit305receives an inquiry on the aborted process320.

When the abort signal is detected by the detecting unit301, the generating unit308generates a core file that includes the content stored in a given storage area at the time of the detection. For example, a file of the name “core” and in which the content of a memory and/or a register is stored is generated. The generating unit308generates the core file inclusive of the information on the details concerning the execution of the process obtained by the obtaining unit302.

The function of the generating unit308may be included in the kernel310in advance. In such a case, the generating unit308may revise the core file generated by the kernel310to include the details concerning the execution of the process.

Two embodiments of operation upon the occurrence of an abort will be described using an example in which an application that is executed by a user via the information processing apparatus200is aborted for some reason. A first embodiment describes an information processing apparatus200that does not include the generating unit308or the generating unit308thereof malfunctions and thus, no core file is generated. A second embodiment describes an information processing apparatus200that includes the generating unit308and thus, the core file is generated.

In the first embodiment, information concerning the sender of the abort signal is stored upon the occurrence of the abort, thereby enabling the executor of the aborted process to verify the process. A sender-side process of the information processing apparatus200for sending the abort signal, and a recipient-side process thereof that receives the abort signal and is aborted will be described below.

FIG. 4is a flowchart of a procedure of process verification support according to the first embodiment. A sender-side process410depicted inFIG. 4is a flowchart of sending to a process under execution, a signal (for example, a signal “kill”) instructing an abort. A recipient-side process420is a flowchart of receiving the abort instruction, and aborting the process under execution.

A kernel memory430includes, along with a conventional process information storage unit431, a signal transmission history storage unit432and a signal sender information storage unit433since the present embodiment requires a procedure for storing information concerning the abort.

As depicted inFIG. 4, when an abort occurs, the sender-side process410transmits a signal (step S411) and collects signal sender information with respect to the signal (step S412).

The sender-side process410also obtains from the process information storage unit431, information concerning the signal transmission process.FIG. 5is a schematic of a configuration of process information. As depicted inFIG. 5, the process information is stored in the process information storage unit431as a process structure500.

The process structure500depicted inFIG. 5includes: (1) exec501indicating a v-node structure; (2) parent502indicating a parent process structure; (3) pid503indicating a process ID structure; and (4) user504indicating a user structure, etc. From these structures, information for verifying the details concerning the execution of the process of the sender of the signal, at the time of the abort is obtained.

For example, from the exec501, an i-node510indicating an i node and an executable file511on the disk are obtained. From the parent502, a parent included in a parent process structure520and a parent-of-parent (i.e., grandfather) process structure521can be obtained. From the pid503, a pid530indicating the identity of the sender (e.g., a character string indicating the sender ID, etc.) is obtained. From the user504, an exec540is obtained as the content of the signal sent by the sender. The exec540includes a command name (e.g., “kill”) and parameters.

As step S412of the sender-side process410, a transmission time, stack information, the type of signal, and information concerning the identity of the recipient are obtained from the sender-side process410itself as the signal transmission history.

The time of transmission is obtained from a time of day (TOD) that is included in the information processing apparatus200and holds the number of seconds from Jan. 1, 1970. The obtained information can be converted into the form of year-month-day.

The stack information is placed at a given location in a virtual memory space of the user process itself.FIG. 6is a chart of an exemplary configuration of the virtual memory space. As depicted inFIG. 6, stack information is stored in the address space600for each call of a function, and includes an address (i.e., which command on the memory is executed) and parameters.

As described above, information is obtained from the process information storage unit431and the sender-side process410itself as the signal sender information (step S412), and is stored into the signal transmission history storage unit432(at step S413).

FIG. 7is a schematic of a configuration of the signal transmission history storage unit. The signal sender information (e.g., signals XXX1to XXXF) obtained from the signal information is cyclically stored into the signal transmission history storage unit432depicted inFIG. 7.

The signal sender information is configured as depicted in a table700. For example, the signal sender information is configured by data for obtaining information (e.g., the data below) to verify which process is executed in the recipient-side process420when the signal is sent.

Transmission time: verified based on TOD (elapsed time from start of the system)

Type of signal: verified based on the signal number

Identity of sender: verified based on the PID and the exec character string. The PID is the process number of the process that has sent the signal, and the exec character string is a character string that includes “command name+option,” such as “kill 29999.”

State at the time of transmission: verified based on the stack information and the process tree information. The stack information, which corresponds to the output of pstack command of UNIX, includes “address of function+name of function+parameters+offset in function” and is used for checking the flow of the process that has sent the signal. The process tree information, which corresponds to the output of ptree command of UNIX, includes the process number and a character string indicating “command name+option” and is used for checking the parent process and higher process(es) of the process that has sent the signal

Identity of the recipient: verified based on the process number of the process that receives the PID signal

The reference of the description returns toFIG. 4, after storing the signal transmission history that includes the sender information described above, the sender-side process410notifies the recipient of the signal (step S414), and the operations end. The notification at step S414is also stored into the process information storage unit431as a part of the sender-side process410.

The recipient-side process420refers to the process information storage unit431and checks the received signal (step S421) to determine whether an instruction for abort has been received (step S422). If an instruction for abort has been received (step S422: YES), the recipient-side process420retrieves from the signal transmission history432, the signal sender information corresponding to the signal checked at step S421(step S423).

Using the signal sender information extracted at step S423, the recipient-side process420generates a file of a given format that is easy to use for the user (step S424). The generated file is stored into the signal sender information storage unit433to be referred to during process verification. The recipient-side process420executes signal processing (step S425), and the operations end. Needless to say, the processing at step S425is also stored into the process information storage unit431as a part of the recipient-side process420.

FIG. 8is a schematic of exemplary signal sender information output. Text data800depicted inFIG. 8is an example of the file generated at step S424, and the signal sender information is output as a text that can be verified by the user. Components of the text data800have the following meanings.

Time: time of transmission

Sender: Identity of sender (PID)

Command: Identity of sender (exec character string)

Stack Trace: State at time of transmission (stack information)

Process Tree: State at time of transmission (process tree information)

Receiver: Identity of recipient (PID)

For example, “Command” executes Kill command to a process18904, and “—ABRT” designates the signal number6. “Stack Trace” indicates that functions “start( )” “main( )” . . . and “kill( )” are called in this order. “Process Tree” indicates that a process217starts a process18070that starts a process18080, and csh (like DOS prompt) of the process18080executes the kill command.

As described above, in the first embodiment, the signal sender information is obtained and stored when a process under execution is aborted. Further, the signal sender information necessary for process verification is stored as a file of a given format that is easy to use for the user, thereby enabling the user to refer to necessary information immediately.

As described above, the second embodiment describes process verification support when an abort signal is detected at an information processing apparatus200capable of generating the core file.

FIG. 9is a flowchart of a procedure of process verification support according to the second embodiment. Compared toFIG. 4, the procedure of the recipient-side process420depicted inFIG. 9is partially changed, and in a kernel memory930, the signal sender information storage unit433is replaced with a signal sender information storage unit900having the core file. Other operations are similar to those of the first embodiment and thus, description thereof is omitted.

In the second embodiment, if aborted, the recipient-side process420executes the signal processing (step S901); generates, from the signal sender information (step S902), a file of a given format that is easy to use for the user; incorporates the file into the core file; and stores the core file into the signal sender information storage unit900.

As described above, the signal sender information is incorporated into a conventional core file if a core file is generated when a process is aborted, thereby enabling the user to verify the process based on both information included in the conventional core file and the signal sender information.

As described above, according to the present embodiment, information on the details concerning the execution of the process referred by the kernel at the time of the detection of the abort signal from the kernel is obtained and stored into the memory. The stored information is information on the details concerning the execution of the process causing the output of the abort signal by kernel. Thus, information stored in the memory enables process verification and identification of the cause of the abort.

The process verification support method described in the present embodiment may be implemented by executing a prepared program on a computer such as a personal computer and a workstation. The program is stored on a (tangible) computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, read out from the recording medium, and executed by the computer. The program may be a transmission medium that can be distributed through a network such as the Internet.

The information processing apparatus200described in the present embodiment can be implemented by an application specific integrated circuit (ASIC) such as a standard cell or a structured ASIC, or a programmable logic device (PLD) such as a field-programmable gate array (FPGA). Specifically, for example, functional units (detecting unit301to output unit307) of the information processing apparatus200are defined in hardware description language (HDL), which is logically synthesized and applied to the ASIC, the PLD, etc., thereby enabling manufacture of the information processing apparatus200.

According to the embodiments, when an abort occurs, the cause can be efficiently identified irrespective of the skill of the user.