JP2007133604A - Computer system, operational state determination program and operational state determination method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To identify a cause of occurrence of dormancy of an application program. <P>SOLUTION: A cause function list update section 31a stores a function having the possibility of causing a process dormant state as a cause function list 41, and an operation abnormality determination section 32 determines the operation abnormality of a process. Furthermore, if the process is in a dormant state, application stack information 42 in which the function execution history of the process is recorded, and the cause function list 41 are compared so as to identify which function has caused the process dormancy. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a computer system, an operation state determination program for determining an operation state of an application program running on the computer system, and an operation state determination method, and more particularly to a computer system and operation state determination capable of specifying the cause of sleep in an application program. The present invention relates to a program and an operation state determination method.

  Conventionally, various countermeasures have been devised when an abnormality occurs in an application program executed on a computer system. For example, Patent Document 1 records a context immediately before a process generated by an application program calls a function, and when an abnormality occurs after function execution, the recorded context is written back to the CPU, and the original A technique for executing an alternative function in which a specific function is omitted instead of a function is disclosed.

JP 2001-109635 A

  However, since the above-described conventional technology does not consider the history of what function is called and has caused an abnormality, for example, when the last function called is the cause of the abnormality. There was a problem that the abnormality could not be detected correctly.

  Furthermore, there is a problem that even if it is detected that an abnormality has occurred, it cannot be determined in which waiting state of the process the abnormality has occurred.

  The present invention has been made in order to solve the above-described problems caused by the prior art and to solve the problems. A computer system, an operation state determination program, and an operation state determination method capable of identifying the cause of sleep in an application program The purpose is to provide.

  In order to solve the above-mentioned problems and achieve the object, a computer system according to the invention of claim 1 is a computer system for executing an application program, and an execution history storage means for storing a function execution history by the application program And a sleep state specifying means for specifying a function that causes a sleep state with reference to the execution history of the function.

  According to the first aspect of the present invention, the computer system stores the function execution history of the application program, and identifies the function causing the sleep state by referring to the function execution history.

  The computer system according to a second aspect of the present invention is the computer system according to the first aspect, further comprising causal function list storage means for storing a list of functions that can cause the sleep state as a cause function list. When the function stored in the execution history storage unit exists in the cause function list, the state specifying unit specifies that the function is the cause of the sleep state.

  According to the invention of claim 2, the computer system stores a list of functions that can cause a sleep state as a cause function list, and when the function stored in the execution history storage means exists in the cause function list, the function Is identified as the cause of the dormant state.

  The computer system according to a third aspect of the present invention is the computer system according to the first or second aspect, wherein the sleep state specifying means starts from a function whose execution order is later among the functions stored in the execution history storage means. A search for whether or not it exists in the cause function list is sequentially executed, and when a function existing in the cause function list is detected, the function is identified as the cause of the sleep state.

  According to the third aspect of the present invention, the computer system sequentially executes a search as to whether or not the execution order exists in the cause function list from the later function among the functions stored in the execution history storage means, and the cause function list When a function existing in is detected, the function is identified as the cause of the sleep state.

  According to a fourth aspect of the present invention, there is provided the computer system according to the second or third aspect, wherein the cause function list includes each function and the type of wait state of the application program when the function is the cause. The sleep state specifying means further specifies the type of wait state of the application program when the function that causes the sleep state is specified.

  According to the fourth aspect of the present invention, the computer system stores each function and the wait state of the application program when the function is the cause in association with each other in the cause function list and stores the function that causes the sleep state. If the application program is specified, the type of wait state of the application program is further specified.

  According to a fifth aspect of the present invention, there is provided a computer system according to the second, third or fourth aspect, further comprising a cause function list updating means for adding and / or deleting a function stored in the function list storage means. It is characterized by having.

  According to the invention of claim 5, the computer system stores a list of functions that can cause a sleep state as a cause function list and updates the function appropriately, and the function stored by the execution history storage means exists in the cause function list. Then, the function is identified as the cause of the sleep state.

  According to a sixth aspect of the present invention, in the computer system according to the fifth aspect, the causal function list update means is based on a change in the operating state of the application program and / or a change in the hardware connection state. The addition and / or deletion of the function is performed.

  According to the invention of claim 6, the computer system stores a list of functions that can cause a sleep state as a cause function list, and updates appropriately based on changes in the operating state of the application program and the connection state of the hardware, When the function stored in the execution history storage means exists in the cause function list, the function is identified as the cause of the sleep state.

  An operating state determination program according to a seventh aspect of the invention is an operating state determination program for determining an operating state of an application program operating on a computer system, and storing a function execution history by the application program And a sleep state specifying procedure for specifying a function that causes a sleep state with reference to the execution history of the function.

  According to the seventh aspect of the present invention, the operation state determination program stores the function execution history by the application program, and identifies the function causing the sleep state by referring to the function execution history.

  According to an eighth aspect of the present invention, there is provided an operation state determination program that causes the computer to further execute a determination procedure for determining whether or not the program execution unit is in a sleep state. And

  According to the eighth aspect of the present invention, the operation state determination program stores the function execution history by the program execution unit of the application program, determines whether or not the program execution unit is in a sleep state, and the program execution unit is in a sleep state. If it is in the state, refer to the function execution history to identify the function that caused the sleep state.

  An operation state determination program according to a ninth aspect of the invention is characterized in that, in the seventh aspect of the invention, whether or not the program execution unit is in a sleep state is acquired from the outside.

  According to the ninth aspect of the invention, the operation state determination program stores the function execution history of the application program according to the program execution unit, acquires from the outside whether or not the program execution unit is in a sleep state, and executes the program execution unit. When is in a sleep state, the function execution history is identified by referring to the function execution history.

  An operation state determination method according to the invention of claim 10 is an operation state determination method for determining an operation state of an application program operating on a computer system, and storing a function execution history by the application program And a sleep state specifying step of specifying a function causing the sleep state with reference to the function execution history.

  According to the invention of claim 10, the operation state determination method stores the function execution history by the application program, and identifies the function causing the sleep state by referring to the function execution history.

  According to the first aspect of the present invention, the computer system stores the function execution history by the application program, and identifies the function causing the sleep state by referring to the function execution history. There is an effect that a computer system capable of specifying the cause can be obtained.

  According to the second aspect of the present invention, the computer system stores a list of functions that can cause a sleep state as a cause function list, and when the function stored by the execution history storage means exists in the cause function list, Since the function is identified as the cause of the sleep state, it is possible to obtain a computer system that can easily identify the cause of the occurrence of sleep in the application program.

  According to a third aspect of the present invention, the computer system sequentially executes a search as to whether or not the execution order exists in the cause function list from the later function among the functions stored in the execution history storage means, When a function existing in the list is detected, the function is identified as the cause of the sleep state, so that it is possible to obtain a computer system capable of reliably specifying the cause of the sleep of the application program.

  According to the invention of claim 4, the computer system stores each function and the wait state of the application program when the function is the cause in association with each other in the cause function list, and causes the sleep state. When the function is specified, the type of wait state of the application program is further specified, so that it is possible to obtain a computer system capable of specifying the cause of sleep of the application program and the wait state generated by sleep. .

  According to the invention of claim 5, the computer system stores a list of functions that can cause a sleep state as a cause function list and updates it appropriately, and the function stored by the execution history storage means exists in the cause function list. In this case, since the function is identified as the cause of the sleep state, it is possible to obtain a computer system capable of accurately specifying the cause of the sleep of the application program.

  According to the invention of claim 6, the computer system stores a list of functions that can cause a sleep state as a cause function list and updates it appropriately based on changes in the operating state of the application program and the connection state of the hardware. When the function stored in the execution history storage means is present in the cause function list, the function is identified as the cause of the sleep state, so the cause of the sleep of the application program is specified according to the state of the computer system. There is an effect that a possible computer system can be obtained.

  According to the invention of claim 7, the operation state determination program stores the function execution history by the application program, and refers to the function execution history to identify the function causing the sleep state. There is an effect that it is possible to obtain an operation state determination program capable of specifying the cause of the occurrence of sleep.

  According to the eighth aspect of the invention, the operation state determination program stores the function execution history by the program execution unit of the application program and determines whether the program execution unit is in a sleep state. Since the function that caused the sleep state is identified by referring to the function execution history in the sleep state, the occurrence of sleep in the application program is detected, and an operation state determination program capable of specifying the cause function is obtained. There is an effect that can be.

  According to the invention of claim 9, the operation state determination program stores the function execution history by the program execution unit of the application program, acquires from the outside whether the program execution unit is in a sleep state, and executes the program. When the unit is in the dormant state, the function execution history is identified by referring to the function execution history, so the operation state determination that can identify the cause of the dormancy using the detection result of the external application There is an effect that a program can be obtained.

  Further, according to the invention of claim 10, the operation state determination method stores the function execution history by the application program, and refers to the function execution history to identify the function causing the sleep state. There is an effect that it is possible to obtain an operation state determination method capable of specifying the cause of the occurrence of sleep.

  Exemplary embodiments of a computer system, an operation state determination program, and an operation state determination method according to the present invention will be described below in detail with reference to the accompanying drawings.

  FIG. 1 is a schematic configuration diagram showing a schematic configuration of a computer system 1 according to an embodiment of the present invention. As shown in the figure, in the computer system 1, an operating system 10, a monitoring program 11, and a monitoring target application 12 are operating.

  The operating system 10 includes a sleep state specifying unit 21 and an operation information management unit 22 as its software functions. The monitoring program 20 includes a monitoring processing unit 30 as its software function, and the monitoring processing unit 30 includes an application monitoring unit 31, an operation abnormality determination unit 32, and an operation abnormality processing unit 33 therein.

  The storage unit 40 is a recording medium such as a memory, and is used by the operating system 10, the monitoring program 11, and the monitoring target application 12 for storing information.

  The monitoring target application 12 is an arbitrary application program managed by the operating system 10 and monitored by the monitoring program 11. The monitoring target application 12 generates a process (or thread) that is a program execution unit during operation.

  The generated process sequentially executes a plurality of functions and saves each function in the storage unit 40 as application stack information 42. That is, the application stack information 42 stores the function execution history of the process. In addition, operation information 43 indicating information regarding the process is stored in the storage unit 40 for the operation system 10 to use for process management.

  The application monitoring unit 31 monitors the operation state of the monitoring target application 12. In addition, the application monitoring unit 31 includes a cause function list update unit 31a.

  The cause function list update unit 31a performs a process of updating the contents of the cause function list 41 stored in the storage unit 40. The cause function list 41 is a list of functions that can cause a sleep state among functions executed by a process. Here, the functions that need to be included in the cause function list 41 vary depending on what type of monitoring target application is operating.

  For example, if a USB device is connected to the computer system 1 and a USB driver that manages the input / output of the USB device is operating as the management target application 12, a function related to the input / output of the USB device is the function of the USB driver. Since it may cause sleep, it is necessary to register in the cause function list 40.

  However, when the USB device is not connected or when the USB driver is not activated, it is not necessary to register a function related to input / output of the USB device in the cause function list 40.

  Therefore, the cause function list update unit 31a appropriately updates the contents of the cause function list 41 based on changes in the operation state of the monitoring target application 12 and the hardware connection state.

  The operation abnormality determination unit 32 detects an operation abnormality of the monitoring target application by determining whether each process has an operation abnormality based on the operation information 43 of the process belonging to the monitoring target application 12.

  Specifically, the operation abnormality determination unit 32 makes an operation information acquisition request to the operation information management unit 22 at a predetermined timing. In response to this request, the operation information management unit 22 reads the operation information 43 from the storage unit 40 and passes it to the operation abnormality determination unit 32. The operation abnormality determination unit 32 determines whether an operation abnormality such as “infinite loop”, “CPU waiting state”, or “I / O waiting state” has occurred in the monitoring target application 12 from the acquired operation information 43.

  Here, the “I / O waiting state” is a state in which the execution of the function issued by the process is not completed due to, for example, resource competition, and the process is stopped while waiting for the completion of the execution of the function (that is, the process is sleeping) It is.

  When the process is in the sleep state in this way, the operation abnormality determination unit 32 specifies the memory used as the application stack information 42 by the process in the sleep state, and the sleep state specification unit 21 To output the sleep state specific request.

  When receiving the sleep state specification request, the sleep state specifying unit 21 uses the cause function list 41 and the application stack information 42 to specify the function that caused the sleep state. Furthermore, the waiting state specifying unit 21a in the dormant state specifying unit 21 specifies the type of waiting state of the monitoring target application 12 that has experienced an abnormal operation. Then, the sleep state specifying unit 21 reports to the operation abnormality determination unit 32 the function that caused the sleep state and the type of the wait state of the monitoring target application 12.

  When the operation abnormality determining unit 32 determines that the operation is abnormal, the operation abnormality time processing unit 33 is the type of the abnormality, and if the process is in the sleep state, the function or wait state that causes the sleep state. Based on the type, the termination processing of the corresponding monitoring target application 12 or error display processing is performed.

  As described above, when the computer system 1 detects that the process has entered the sleep state, it can identify which function caused the process sleep from the function execution history of the process.

  Subsequently, the abnormality determination process by the operation abnormality determination unit 32 will be further described. First, FIG. 2 shows the relationship between the operation information used in abnormality determination and the abnormality type determined based on the operation information. In the abnormality determination process by the operation abnormality determination unit 32, paying attention to switching of processes operating on the CPU (hereinafter referred to as “context switch”), the monitoring target application is used using the relationship between the change in the number of context switches and the abnormality type. Detects abnormal operation.

  Here, the context switch will be described. In order to realize a multi-process environment on a single CPU computer, it is necessary to perform scheduling so that a plurality of processes are simultaneously operating by sequentially switching processes operating on the CPU. For example, in the case of real-time scheduling, context switching is performed by a timer interrupt, and a process waiting for execution is loaded on the CPU in place of the process being executed. In the case of round robin scheduling, a time slice is assigned to each process, and when this time slice is used up, a context switch is performed to switch the execution process.

  Such context switches include a spontaneous context switch and a spontaneous context switch. Here, the spontaneous context switch is a context switch that is caused by releasing the execution right on the CPU itself so that the process running on the CPU acquires resources such as input / output processing and semaphore. Say. Further, the spontaneous context switch refers to a context switch caused by factors other than the process being executed due to the above-described scheduling of the operating system or the like.

  The count up of these context switches is performed, for example, in the following procedure. That is, when the operating system detects the above-described spontaneous context switch, the control is transferred from the process that releases the CPU to another process, and the number of spontaneous context switches on the memory is incremented. On the other hand, when the above-described other context switch is detected, the execution of the process being executed is interrupted, the control is transferred to the interrupt process, and the number of other context switches on the memory is incremented.

  Even when an operating system that does not have such a context switch count-up function is used, the number of times that a process issues an I / O request to the hardware, the number of times an interrupt occurs, and the like are monitored. Such a count-up function can be realized.

  As described above, since the context switch is caused when the execution process is switched, it is possible to detect an abnormal operation of the process by paying attention to the number of context switches.

  Specifically, as shown in FIG. 2, in the case of an abnormal operation due to an infinite loop, the process state is being executed and the number of spontaneous context switches has increased, but the number of spontaneous context switches has changed. It will be in a state that is not. That is, although the context switch is caused by the scheduling of the operating system, the processing of the process is not completed, so that the state that does not cause the spontaneous context switch continues. Therefore, it is determined that a process in which such a state continues for a predetermined time is abnormal in operation because it is highly likely that the CPU has been used for a long time due to an infinite loop.

  In the case of an abnormal operation due to waiting for the CPU, the process state is being executed, and neither the number of spontaneous context switches nor the number of spontaneous context switches changes. If this state continues for a predetermined time, it is highly likely that the execution of the process is hindered by another process, so it is determined that the operation is abnormal due to the CPU waiting.

  In the case of an abnormal operation due to waiting for I / O, the process is waiting, and neither the number of spontaneous context switches nor the number of spontaneous context switches changes. If such a state continues for a predetermined time, it is highly likely that the I / O processing of the process is hindered due to resource contention with another process, and so it is determined that the operation is abnormal due to I / O waiting.

  As described above, in the abnormality detection processing according to the present invention, attention is paid to the context switch, and the operation abnormality is detected by associating the change in the number of context switches with the duration of the process state. An abnormal operation of the target application can be detected.

  Next, a specific example of the cause function list 41 will be described with reference to FIG. As shown in the figure, the cause function list 41 stores “waiting state factor”, “function”, and “address” in association with each other.

  The item of “function” is a group of functions that may cause a process sleep state such as “usb_read” and “hdd_write”, and the “address” indicates where the function is stored in the storage unit 40. It is information which shows.

  The “waiting state factor” is information indicating what waiting state the monitoring target application 12 will enter when the process enters the process sleep state due to the function. For example, in the process sleep state caused by the function “usb_read”, the “wait state factor” is “USB”, and the monitoring target application 12 is in a wait state due to “USB abnormality” (for example, a device connected to the USB responds) To stop waiting for a response. Similarly, in the process sleep state caused by the function “hdd_write”, the “waiting state factor” is “HDD”, and the monitoring target application 12 is in a waiting state due to “HDD abnormality” (for example, the physical state of the HDD Due to a crash or data corruption, the data cannot be read or written correctly and is stuck waiting for a response.

  Next, the relationship between the function execution by the process and the application stack information 42 will be described with reference to FIG. In the figure, when the process executes the function “usb_read”, the function “usb_read” calls the function “f1” in the process. Similarly, the function “f1” calls the function “f2” in the process, and the function “f2” further calls the function “3”.

  Then, the state of the CPU when these functions “usb_read”, “f1”, “f2”, “f3”, and “f4” are executed is saved in the application stack information 42, respectively. At this time, evacuation is executed from under the application stack information 42 in accordance with the function execution order.

  Therefore, when this process enters the sleep state, the function saved at the top of the application stack information 42 (in the figure, the function “f3”) becomes the last executed function. Therefore, if this last executed function is registered in the cause function list 41, the last executed function can be specified as the cause function of process sleep.

  On the other hand, if the last executed function is not registered in the application stack information 42, the function executed before that (the function that called the last executed function; function “f2” in FIG. 4) is the cause function list. Whether or not the function is registered is identified, and if it is registered, the function is specified as a cause function of process sleep. If not registered, the cause function list 41 is searched using the previous function as a key.

  In this way, the cause function list 41 is searched in order from the last executed function, and the cause function of the process sleep can be identified by going back to the function registered in the cause function list 41. When the function is traced, the return register and frame pointer stored in the memory area used by each function of the application stack information 42 (information indicating the start address of the memory area used by the previous function) ).

  Next, the processing operation of the computer system 1 will be described with reference to the flowchart of FIG. The processing flow shown in the figure is periodically executed by the monitoring program 11.

  When this processing flow is started, first, the operation abnormality determination unit 32 acquires the operation information 43 (step S101). Then, the process operation abnormality is determined using the acquired operation information 43 (step S102).

  As a result, if there is no abnormal operation process (No at Step S103), the process is terminated as it is. On the other hand, if an abnormal operation process exists (step S103, Yes), it is determined whether or not the process is in a sleep state (step S104).

  If the process is in a sleep state (step S104, Yes), a sleep state specifying process (step S105) by the sleep state specifying unit 21 is further executed.

  If the process is not in the sleep state (No in step S104) or after the sleep state specifying process (step S105), the abnormal operation processing unit 33 performs the termination process of the corresponding monitoring target application 12 based on the content of the abnormal operation, An abnormal process such as an error display process is executed (step S106), and the process is terminated.

  Subsequently, the processing content of the sleep state specifying process (step S105) by the sleep state specifying unit 21 will be further described with reference to the flowchart of FIG.

  As shown in the figure, the sleep state specifying unit 21 first reads the top function of the abnormal operation stack used by the sleep state process (step S201), and searches the cause function list 41 using the read function as a key. (Step S202).

  As a result, if the read function does not exist in the cause function list 41 (step S203, No), the next function is read (step S205), and the cause function list 41 is searched using the read function as a key (step S202). ).

  If the read function exists in the cause function list 41 (step S203, Yes), a waiting state is specified based on the read function (step S204), and the process ends.

  As described above, in the computer system according to the present embodiment, the cause function list backward unit 31a stores a function that may cause the process sleep state as the cause function list 41, and the process enters the sleep state. If the application stack information 42 in which the function execution history of the process is recorded is compared with the cause function list 41, it is possible to specify which function causes the process sleep.

  Thus, by identifying the cause of process sleep at the function level, it is possible to restore the sleep state while minimizing the influence on other applications. Therefore, it is suitable for a system that requires high stability, such as a vehicle-mounted system, a car navigation device, and a vehicle operation control device.

  For example, if the present invention is applied to an in-vehicle device in which a music playback program and a navigation program operate on the same operating system, even if the music playback program enters a sleep state, the music playback program can be operated normally. Can be restored.

  In the present embodiment, the process is mainly described as an example of the program execution unit. However, it goes without saying that the present invention can be similarly applied to other program execution units such as threads.

  In this embodiment, the function execution history is acquired by referring to the application stack information used by the process at the time of operation. For example, the operating system manages the function execution history by the process as the operation information. It is good also as a structure which acquires the execution history of a function from information.

  Furthermore, in this embodiment, the operation abnormality determination is executed in the monitoring program which is one of the application programs, and the sleep state is specified by the operating system. It can be implemented by any configuration, such as executing both the state determination within the monitoring program and performing both the operation abnormality determination and the sleep state determination within the operating system.

  Furthermore, in the present embodiment, the case where the occurrence of the process sleep state is detected by monitoring the context switch has been described as an example. However, any method may be used as a method for detecting the process sleep state occurrence. it can.

  As described above, the computer system, the operation state determination program, and the operation state determination method according to the present invention are useful for application operation management, and are particularly suitable for specifying the cause of application program sleep.

1 is a schematic configuration diagram showing a schematic configuration of a computer system according to an embodiment of the present invention. It is a figure which shows the relationship between operation information and abnormality classification. It is explanatory drawing explaining the specific example of the cause function list | wrist shown in FIG. It is explanatory drawing explaining the relationship between execution of the function by a process, and application stack information. It is a flowchart explaining the processing operation of the computer system shown in FIG. It is a flowchart explaining a dormant state specific process.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Computer system 10 Operating system 11 Monitoring program 12 Monitoring target application 21 Sleep state specific | specification part 21a Wait state specific | specification part 22 Operation | movement information management part 30 Monitoring processing part 31 Application monitoring part 31a Cause function list update part 32 Operation | movement abnormality determination part 33 Operation | movement abnormality Time processing unit 40 Storage unit 41 Cause function list 42 Application stack information 43 Operation information

Claims (10)

A computer system for executing an application program,
Execution history storage means for storing an execution history of the function by the application program;
A sleep state specifying means for specifying a function that causes a sleep state with reference to the execution history of the function;
A computer system comprising:   Causal function list storage means for storing a list of functions that can cause the sleep state as a cause function list, wherein the sleep state specifying means includes the function stored in the execution history storage means in the cause function list. The computer system according to claim 1, wherein the function is specified as the cause of the sleep state.   The sleep state specifying unit sequentially executes a search for whether or not the execution order is present in the cause function list from the functions stored in the execution history storage unit, and the functions existing in the cause function list. 3. The computer system according to claim 2, wherein the function is identified as the cause of the sleep state at the point of time when the signal is detected.   The cause function list stores each function and the type of wait state of the application program when the function is the cause in association with each other, and the sleep state specifying unit specifies the function that causes the sleep state 4. The computer system according to claim 2 or 3, further specifying the type of waiting state of the application program.   5. The computer system according to claim 2, further comprising cause function list update means for adding and / or deleting functions stored in the function list storage means.   The said cause function list update means performs the addition and / or deletion of the said function based on the change of the operation state of an application program, and / or the change of the connection state of hardware. Computer system. An operation state determination program for determining an operation state of an application program operating on a computer system,
A storage procedure for storing a function execution history by the application program;
A sleep state identification procedure for identifying a function that causes a sleep state with reference to the execution history of the function;
An operating state determination program that causes a computer to execute.   The operation state determination program according to claim 7, further causing a computer to execute a determination procedure for determining whether or not the program execution unit is in a sleep state.   8. The operating state determination program according to claim 7, wherein whether or not the program execution unit is in a sleep state is acquired from the outside. An operation state determination method for determining an operation state of an application program operating on a computer system,
A storage step of storing a function execution history by the application program;
A sleep state identification step for identifying a function that causes a sleep state with reference to the execution history of the function;
The operation state determination method characterized by including.

Images