JP2009251681A - Expansion method for stack region and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To safely continue the execution of a task whose stack overflow has occurred. <P>SOLUTION: A method for extending a stack region includes: waiting for the detection of stack overflow in step S101; retrieving a task whose stack region is destroyed due to its stack overflow in step S102; stopping the task whose stack region is destroyed in step S103; and extending the stack region of the task whose stack overflow has occurred in step S104. This processing brings about such effects that it is possible to continue the execution of the task whose stack overflow has occurred without using any virtual storage or the like, and to guarantee the execution of the task whose stop is not permitted. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a stack area expansion method and program for expanding a stack area when a stack overflow is detected in a multitask system.

  Conventionally, there is a technique related to a method for expanding a stack area in a multitask system, in which a reserved area of a stack area is set for each task, and the reserved area is used as a stack area when a stack overflow occurs (patent) (Ref. 1).

  The technology according to Patent Document 1 relates to a multi-thread task stack allocation method for allocating tasks of a plurality of threads constituting a multi-thread task. This technique is particularly effective when applied to a multi-thread task stack allocation method for a multiprocessor system that executes a large-scale vector program for a supercomputer on the premise of page fixing. In addition, a reserved area is set at the upper limit of the stack area for each thread existing in the virtual storage space, and when the reserved area is used for the first time, the storage area of the virtual storage space is allocated to the used area of the stack area, and the stack It is characterized by using the area used.

  In addition, when multitask processing is performed by a microprocessor built into a device, there is one that detects a stack overflow by comparing with initialization data in the stack area and stops the task that caused the stack overflow (patent) (Ref. 2).

  The technology according to Patent Document 2 manages tasks so that when a multitask process is performed on a microprocessor, a stack area to which a specific task is allocated overflows and the stack area of another task is not used. To do. This is an effective technique for preventing the runaway of the microprocessor.

  Other methods for detecting stack overflow include the following. Patent Document 3, Patent Document 4, Patent Document 5, and Patent Document 6 are all configured with a stack overflow detection circuit outside the CPU, and before the stack area is destroyed by comparing the stack area with a stack pointer or similar register. This is notified by an interrupt or the like.

  Further, Patent Document 7 judges stack overflow in periodic interrupt processing. In this technology, in order to detect stack overflow without adding special hardware, it is detected after destroying the stack area and variable area used by other tasks, etc., or in the stack area. A continuous spare area is initialized with a special value. Then, it is detected by examining at a certain timing that the special value has been changed to another value.

  The above techniques are mentioned as the background art of the present invention.

JP-A-9-167114 JP 2000-76081 A JP-A-62-212733 Japanese Patent Laid-Open No. 2-8945 Japanese Patent Laid-Open No. 9-198258 JP 2000-20352 A Japanese Patent Laid-Open No. 2004-157762

  However, the above-described conventional technique has a problem that task execution cannot be continued unless the stack area is expanded in the virtual storage area, or a task that has caused a stack overflow cannot be continued.

  For example, if a sufficient stack area for a task for controlling the machine is not secured due to a mistake in the design stage, a stack is unexpectedly consumed and a stack overflow occurs. Originally, it is desirable to secure a sufficient stack area at the design stage, but it may be difficult to estimate the stack consumption.

  Normally, it is necessary to take a safe way to stop the system even if a stack overflow occurs, but it may be safer to perform error handling while it is running, so the task that caused the stack overflow is stopped. It is not always good to do. The present invention solves such problems.

The stack area expansion method according to the present invention is a stack area expansion method for expanding a stack area of a task that has caused a stack overflow, the step of waiting for detection of the stack overflow, and the stack area being destroyed by the stack overflow. The method includes a step of searching for a task, a step of stopping a task in which the stack area is destroyed, and a step of expanding the stack area of the task that has caused the overflow.
The program of the present invention is a program for causing a computer to execute a stack area expansion method for expanding the stack area of a task that has caused a stack overflow. A program for causing a computer to execute a step of searching for a task in which a stack area is destroyed, a step of stopping a task in which the stack area is destroyed, and a step of expanding the stack area of the task that has caused the overflow is there.
Note that the task and thread in the present invention are used in the same meaning with different names, but the task described in Patent Document 1 is expressed as composed of one or a plurality of threads. The task corresponds to a process handled in the UNIX (registered trademark) process model.

  According to the present invention, it is possible to continue execution of a task that has caused a stack overflow without using virtual memory or the like without stopping, and it is possible to guarantee execution of a task that is not allowed to be stopped. .

(First embodiment)
Embodiments of the present invention will be described below. FIG. 1 is a flowchart showing a processing flow of a stack area expansion method according to the present invention. Hereinafter, the flow of processing will be described step by step together with an example implemented in a specific multitask system.

  Although a real-time OS such as μITRON is assumed as a multitask system, this embodiment does not limit the multitask system, and can be implemented in a general embedded multitask system that does not employ virtual memory. Is. In the present embodiment, the process from the start to the end based on the flowchart shown in FIG. 1 is realized as one task that is repeated until the system stops.

  When a task is generated and the execution right is transferred to the task by the system, the process shown in the flowchart is started and step S101 is executed. In step S101, it waits for detection of a stack overflow. The method for detecting the stack overflow is left to the above-described prior art, and detailed description thereof is omitted here. However, for example, the stack overflow is detected by the method described in Patent Document 2 without changing the hardware. When the stack overflow is detected, step S101 ends and the next step S102 is executed.

  In step S102, a task whose stack area is destroyed by the stack overflow is searched. When a stack overflow occurs, the value (address) is normally stored in the stack pointer. It is possible to search which task's stack area is about to be destroyed from the stack area start address and stack size for each task managed by the task management table 301 shown in FIG. In the case of a task management table in which the stack size is omitted, a task that is damaged by stack overflow can be identified by comparing the stack start address of each task with the size of the stack pointer.

  Further, in the method of Patent Document 2, there is a case where the last part of the stack boundary is destroyed, but even in such a case, the stack area of the task adjacent to the stack area is treated as being destroyed.

  In this way, in step S102, a task whose stack area is destroyed due to stack overflow is searched, and the next step S103 is executed.

  In step S103, the task that destroys the stack area is stopped. In a multitask system, a task to be executed next is often managed in a task queue ordered in a list for each task priority as shown in FIG.

  FIG. 4A shows a task queue before the task is stopped. Task priority 1 to task priority 3 are defined. Task 4, task 1, and task 6 are queued in the task priority 1 task queue, and task 1 is being executed. Task 2 is queued in the task queue with task priority 2 and is waiting for the execution right to be acquired. Task 5 and task 3 are queued in the task queue with task priority 3.

  This task starting from step S101 corresponds to task 4 in FIG. 4 and is currently being executed at the top of task priority 1. In the situation of FIG. 4, the task is stopped by deleting task 2 to be stopped from the task queue. By deleting the task to be stopped from the task queue, the process of step S103 is terminated, and step S104 is executed.

  FIG. 4B shows the state of the task queue after the task is stopped. Here, the task 2 is deleted by moving the task 2 to the stopped state queue. It is left to the multitasking system. In step S104, the stack area of the task causing the overflow is expanded.

  FIG. 2 shows a memory map before task 1 causes stack overflow and destroys the stack area of task 2 (FIG. 2A) and after destruction (FIG. 2B). In step S103, the task 2 is stopped and the stack area of the task 2 is no longer available, so that it can be used as the stack area of the task 1 in which the stack overflow has occurred. Then, as described in claim 2, the stack size of task 2 to be stopped is added to the stack size of task 1 causing the stack overflow from the task management table 301 shown in FIG. 3. As a result, the stack area of task 1 is expanded. When the stack overflow is detected by software as in the present embodiment, the stack area needs to be initialized with a special value. In this case, initialization is performed on the area for expanding the stack before completing step S104. After step S104 is completed, the process returns to step S101 again to wait for a new stack overflow detection.

  By performing as described above, according to the present invention, it is possible to continue the execution without stopping the task that caused the stack overflow without using virtual memory or the like, and the task that is not allowed to stop. Can be guaranteed.

(Second Embodiment)
Next, a second embodiment of the present invention will be described. FIG. 5 is a flowchart showing the flow of processing of claim 3. In this embodiment, the stack overflow is detected by hardware, and the multitask system is notified in the form of an interrupt. As described in the prior art, there are various methods for detecting a stack overflow by hardware, and the description is omitted because it is not the main point of the present invention. However, any method is particularly problematic. There is no.

  For example, Patent Literature 3, Patent Literature 4, Patent Literature 5, and Patent Literature 6 all configure a stack overflow detection circuit outside the CPU, and compare a stack pointer or a similar register with a stack area. As a result, notification is made by an interrupt or the like before destroying the stack area. In the present embodiment, the same method is implemented, and when an interrupt is notified to the system, step S501 in FIG. 5 is executed.

  In step S501, the cause of the interrupt is checked by acquiring the value of the interrupt factor register and the like. If the stack overflow is the cause of the interrupt, the next step is executed. Since the subsequent steps are the same as those in step S102 and subsequent steps in the first embodiment described above, description thereof is omitted, but task 2 is deleted from the task queue after the final step S104 is completed.

  Then, the stack area of task 1 is expanded by being integrated with the stack area of task 2, and finally the process is terminated by returning from the interrupt processing. If the interrupt factor is not a stack overflow in step S501, step S505 is executed.

  In step S505, interrupt processing other than stack overflow is executed, and the interrupt processing ends.

  By carrying out as described above, according to the stack area expansion method of the present invention, execution can be continued without stopping the task that caused the stack overflow without using virtual memory or the like. It is possible to guarantee the execution of tasks that are not allowed to occur.

  Here, FIG. 6 illustrates a computer 600 as an example of a hardware configuration for performing the processing according to the first embodiment and the second embodiment. As shown in FIG. 6, the computer 600 includes a CPU 601, a ROM 602, a RAM 603, and a keyboard controller (KBC) 605 of a keyboard (KB) 609. Furthermore, a CRT controller (CRTC) 606 of a CRT display (CRT) 610 as a display unit and a disk controller (DKC) 607 of a hard disk (HD) 611 and a flexible disk (FD) 612 are provided. Further, a network interface controller (NIC) 608 for connection to the network 640 is included. These units included in the computer 600 are communicably connected to each other via a system bus 604.

  The CPU 601 comprehensively controls each component connected to the system bus 604 by executing software stored in the ROM 602 or the HD 611 or software supplied from the FD 612. That is, the CPU 601 performs a control for realizing the operation in the present embodiment by reading a processing program according to a predetermined processing sequence from the ROM 602, the HD 611, or the FD 612 and executing it.

  The RAM 603 functions as a main memory or work area for the CPU 601. The KBC 605 controls instruction input from the KB 609 or a pointing device (not shown). The CRTC 606 controls the display of the CRT 610. The DKC 607 controls access to the HD 611 and the FD 612 that store a boot program, various applications, edit files, user files, a network management program, a predetermined processing program in the present embodiment, and the like. The NIC 608 exchanges data bidirectionally with devices or systems on the network 640 as necessary.

  In order to realize the present invention, a storage medium in which a program code (computer program) of software that realizes the functions of the above-described embodiments may be used. In this case, the object of the present invention is achieved by supplying the storage medium to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus reads and executes the program code stored in the storage medium.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code itself and the storage medium storing the program code constitute the present invention.

  As a storage medium for supplying the program code, for example, a flexible disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, or the like can be used.

  Needless to say, the OS (basic system or operating system) running on the computer performs part or all of the actual processing based on the instruction of the program code.

  Furthermore, the program code read from the storage medium may be written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer. In this case, based on the instruction of the written program code, the CPU or the like provided in the function expansion board or function expansion unit may perform part or all of the actual processing.

It is a flowchart which shows the flow of a process of this invention. It is a figure which shows the memory map showing the stack area | region before and after the stack overflow of this invention. It is a figure showing the relationship between the task management table of this invention, and a stack area | region. It is a figure showing the task queue which manages the scheduling of the task of this invention. It is a flowchart which shows the flow of the process which concerns on the 2nd Embodiment of this invention. It is a figure which shows an example of the hardware for implementing the process which concerns on this invention.

Explanation of symbols

600 Computer 601 CPU
602 ROM
603 RAM
607 Disk controller (DKC)
611 Hard Disk (HD)

Claims (4)

A stack area expansion method for expanding a stack area of a task that has caused a stack overflow,
Waiting for stack overflow detection;
Searching for a task whose stack area is destroyed by the stack overflow;
Stopping a task that destroys the stack area;
And expanding the stack area of the task that has caused the overflow.   The step of expanding the stack area of the task that caused the overflow is characterized in that the stack area is expanded by setting the stack size of the task that caused the overflow to a value obtained by adding the stack size of the task that is destroyed by the overflow. The method for expanding a stack area according to claim 1.   The step of waiting for the detection of the stack overflow is executed when an interrupt occurs, and the step of searching for the task is executed when it is determined that the cause of the interrupt is a stack overflow. 2. The stack area expansion method according to claim 1, further comprising waiting for detection of a stack overflow by returning to step (a). A program for causing a computer to execute a stack area expansion method for expanding a stack area of a task that has caused a stack overflow,
Waiting for stack overflow detection;
Searching for a task whose stack area is destroyed by the stack overflow;
Stopping a task that destroys the stack area;
A program for causing a computer to execute a step of expanding a stack area of a task that has caused the overflow.

Images