KR102300712B1 - Diagnosing method for cause of stack fault and apparatus thereof - Google Patents

Abstract

The present invention relates to a method for diagnosing a cause of a stack fault in a computing system including a central processing unit and a stack memory, wherein the central processing unit generates a stack fault in the process of repeatedly entering and exiting a context according to the execution of application software. detecting; returning, by the central processing unit, a stack history when the stack fault occurs; and when the stack history is returned, determining, by the central processing unit, a context in which a stack fault occurs based on the stack history.

Description

Method and apparatus for diagnosing the cause of a stack fault

The present invention relates to a method and apparatus for diagnosing a cause of a stack defect, and more particularly, to a stack capable of optimizing a stack area of a corresponding application software by identifying a cause before a stack defect occurs when executing any application software. It relates to a method and apparatus for diagnosing the cause of a fault.

In general, all application software executed on an operator system (OS) executed in a system having a stack configuration central processing unit is executed in a stack manner inside the central processing unit. On the set operator system, the application software performs an independent operation in the name of a task or process by function or work unit, and each task or process has all the priorities set in the operator system (OS).

The operator system performs scheduling according to the priority of the application software to transfer the control right of the central processing unit to the corresponding programs to perform the corresponding function.

At this time, the stack trace of the corresponding task or processors is performed for debugging when any application software and operator system request or software error occurs.

In this case, the conventional technique simply performs tracking from the current stack pointer to the last stack pointer. However, if the stack connected to the linked list is broken for some reason, the stack trace is not performed any more, or even if it does, the stack trace is performed with an invalid value, and valid information cannot be obtained.

In other words, the software stacks the internal state of the software during context switching (that is, the process of saving the state of the currently in progress task (or process, thread) and reading and applying the state value of the next task). It is stored in the area and returned when returning. At this time, when the stack area is insufficient or violated, the operator system (OS) determines that the normal service is no longer possible because it cannot restore the internal state of the software stored in the stack normally, so it generates an error and terminates the software.

As such, whether a stack fault has occurred is determined by looking at whether the pattern of the stack top is broken (that is, whether the stack top is used).

However, since a stack fault occurs when the stack top is used, it is impossible to know which function of the application software uses the stack and how much the stack fault occurred at the time of the actual stack fault. There is no problem.

This is because the function being executed at the time of the stack fault does not always cause the stack fault.

Accordingly, it is difficult to specify the function that caused the stack defect among many functions performed before the occurrence of the stack defect, and when the corresponding stack defect error occurs, it is an unrecoverable error, so debugging is impossible. Therefore, when the stack fault occurs before the stack fault occurs (or in the state in which the stack fault is prevented) when any application software is executed, the cause of this status can be identified when the stack fault occurs, so that the corresponding application software There is a need for a technology that can optimize the stack area of .

The background technology of the present invention is disclosed in Korean Patent Registration No. 10-0866218 (registration on October 24, 2008, stable stack tracking method).

According to one aspect of the present invention, the present invention was created to solve the above problems, and it is possible to optimize the stack area of the corresponding application software by identifying the cause before a stack defect occurs when any application software is executed. It is an object of the present invention to provide a method and apparatus for diagnosing a cause of a stack fault.

A method for diagnosing a cause of a stack fault according to an aspect of the present invention is a method for diagnosing a cause of a stack fault in a computing system including a central processing unit and a stack memory, wherein input and exit of a context are performed according to execution of application software. In the repeated process, the central processing unit detecting the occurrence of a stack defect; returning, by the central processing unit, a stack history when the stack fault occurs; and when the stack history is returned, determining, by the central processing unit, a context in which a stack fault occurs based on the stack history.

In the present invention, the stack history includes a context and a stack pointer value.

In the present invention, prior to the step of detecting the occurrence of the stack fault, in order to prevent the computing system from being down or reset when the stack fault occurs, the central processing unit performs the stack usage in advance with respect to the initially set stack area size. checking whether a specified margin value is reached; and dynamically additionally allocating a temporary stack area when the stack usage reaches a predetermined margin value with respect to an initially set stack area size.

In the present invention, before the step of detecting the occurrence of the stack fault, in order to prevent the computing system from being down or reset when the stack fault occurs, the maximum value used by the central processing unit whenever an event occurs during context switching recording a stack usage and calculating a size of a stack area currently remaining in an initially set stack area; and the central processing unit compares the size of the currently remaining stack area with the maximum usage of the stack used by the context, and when the stack capacity obtained by adding the margin value specified to the maximum usage is greater than the size of the currently remaining stack area, additional and dynamically additionally allocating a temporary stack area by determining that allocation of the dynamic stack area is necessary.

In the present invention, in the step of detecting the occurrence of the stack defect, the central processing unit includes a total of a stack area already used in the initially set stack area and a stack area additionally used in the dynamically additionally allocated temporary stack area. When the sum exceeds the size of the initially set stack area, it is characterized in that it is detected that a stack defect has occurred.

In the present invention, in the step of recognizing a context that generates a stack fault based on the stack history, the central processing unit includes a stack pointer stored when a context is input and a stack returned when the context is terminated and returned. It is characterized by identifying a context that causes a stack fault when the pointer is different.

In the present invention, after the step of recognizing the context in which the stack fault occurs, the step of displaying, by the central processing unit, the context in which the stack fault occurs through a user interface; is characterized in that it further comprises.

In the present invention, after the step of displaying the context in which the stack fault occurs through the user interface, the central processing unit checks whether the application software continues to the user through the user interface; and when the user selects to continue, the central processing unit continues to execute the application software to continuously identify another context that causes a stack fault.

An apparatus for diagnosing a cause of a stack fault according to another aspect of the present invention includes: a stack memory of a computing system; and a central processing unit that detects the occurrence of a stack fault in a process in which input and exit of a context are repeated according to the execution of application software in the computing system. It is characterized in that the context in which the stack fault occurs is identified by analyzing the returned stack history.

In the present invention, the stack history includes a context and a stack pointer value.

In the present invention, the central processing unit, in order to prevent the computing system from being down or reset when the stack fault occurs, before the step of detecting the occurrence of the stack fault, the stack usage is preset for the initially set stack area size. Checking whether a margin value is reached, and dynamically allocating a temporary stack area additionally when the stack usage reaches a predetermined margin value with respect to an initially set stack area size.

In the present invention, the central processing unit, in order to prevent the computing system from being down or reset when the stack fault occurs, before detecting the occurrence of the stack fault, the maximum stack used whenever an event occurs during context switching. A stack obtained by recording the amount of usage, calculating the size of the currently remaining stack area from the initially set stack area, comparing the size of the currently remaining stack area with the maximum usage of the stack used by the context, and summing the margin value specified for the maximum usage When the capacity is larger than the size of the currently remaining stack area, it is characterized in that the temporary stack area is dynamically additionally allocated.

In the present invention, the central processing unit determines the size of the initially set stack area by the sum of the stack area already used in the initially set stack area and the stack area additionally used in the dynamically additionally allocated temporary stack area. When it is exceeded, it is characterized in that it is detected that a stack fault has occurred.

In the present invention, the central processing unit is characterized in that, when the stack pointer stored when a context is input and the stack pointer returned when the context is terminated and returned are different, it is characterized as a context generating a stack fault. .

In the present invention, the central processing unit is characterized in that, upon recognizing the context for generating the stack defect, the context for generating the stack defect is displayed through a user interface.

In the present invention, the central processing unit, after displaying the context for generating the stack fault through the user interface, checks whether the application software continues to the user through the user interface, and when the user selects to continue , characterized in that the application software continues to run to continuously identify other contexts that cause the stack fault.

According to one aspect of the present invention, the stack area of the corresponding application software can be optimized by identifying a cause before a stack defect occurs when any application software is executed. In addition, it is possible to optimize the stack area of the application software by preventing the occurrence of a stack defect when executing arbitrary application software and identifying the cause of this state when the stack defect is in a state where it can occur. .

1 is an exemplary diagram illustrating a schematic configuration of a computing system including a central processing unit and a memory unit according to an embodiment of the present invention;
FIG. 3 is an exemplary view illustrating a situation in which a stack fault occurs in the process of storing and returning a stack pointer according to the execution of a task in FIG. 2;
FIG. 3 is an exemplary view illustrating a situation in which a stack fault occurs in the process of storing and returning a stack pointer according to the execution of a task in FIG. 2;
4 is a flowchart for explaining a process of identifying a cause of a stack defect based on a history previously recorded in the stack in FIG. 2 ;
FIG. 5 is a flowchart for explaining a method of identifying a cause of a stack defect by additionally allocating a temporary stack area when a stack greater than or equal to a margin value for an initially set stack area size is used in FIG. 4 ;
6 is another method of determining the cause of a stack defect by additionally allocating a temporary stack area when a shortage of the stack area is expected by comparing the maximum stack usage with the stack area currently remaining in the initially set stack area in FIG. An example diagram to explain.

Hereinafter, an embodiment of a method and apparatus for diagnosing a cause of a stack defect according to the present invention will be described with reference to the accompanying drawings.

In this process, the thickness of the lines or the size of the components shown in the drawings may be exaggerated for clarity and convenience of explanation. In addition, the terms to be described later are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of the user or operator. Therefore, definitions of these terms should be made based on the content throughout this specification.

1 is an exemplary diagram illustrating a schematic configuration of a computing system including a central processing unit and a memory unit according to an embodiment of the present invention.

As shown in FIG. 1 , the central processing unit 100 (eg, CPU) has a stack configuration and controls the operation of the computing system according to the execution of arbitrary tasks, processes, and applications (or application software). Control.

The memory unit 200 includes a stack unit 201 (or stack memory).

The memory unit 200 stores program data necessary for the system operation and program data according to a method for diagnosing a cause of a stack defect according to the present invention.

As described above, the central processing unit 100 of the stack configuration processes all command execution in a stack manner.

The operator system executed by the central processing unit 100 allocates a stack area of the stack unit 201 so that each application software can be normally performed during execution, and each application performs a given operation using the allocated stack area. carry out

When a stack fault (or stack error, stack overflow error) occurs when executing such an application, or when the stack fault is prevented from occurring when any application software is executed, when the stack fault occurs By detecting a state (that is, a state in which a stack defect may occur), the cause (i.e., the cause of the occurrence of a stack defect) can be diagnosed or identified.

That is, according to an embodiment of the present invention, the central processing unit 100 can diagnose the cause of the stack defect by the method shown in FIGS. 2 to 5 .

FIG. 2 is a flowchart illustrating a process in which applications write a history to a stack according to an embodiment of the present invention, and FIG. 3 is a stack pointer stored and returned according to the execution of a task in FIG. 2 . It is an exemplary diagram to exemplarily explain a situation in which a stack defect occurs in the process of

As shown in FIG. 2 , the central processing unit 100 performs Save and Restore during context switching in the process of executing application software, so that the stack has a task ID (TaskID). (or context) and the stack pointer.

That is, referring to FIG. 2 , when a first context is input (Enter) (S101), an event (Event 1) is recorded as a stack history (S102).

Then, the program function (ie, code) included in the first context is executed ( S103 ). At this time, when the second context is input (Enter) while executing the code (S201), an event (Event 2) for this is recorded as a stack history (S202).

Then, the program function (ie, code) included in the second context is executed (S203), and when the execution of the program function (ie, code) is completed, an event (Event 3) for this is stacked After recording as a history (S204), as the execution of the second context (S203) is completed, the second context is exited (S205), and the previous program function (ie, code) is returned. .

Next, as the execution of the first context (S103) is completed, an event (Event 4) is recorded as a stack history (S104) and the first context is exited (S105).

For reference, when the second context is input (S201), the stack pointer is stored in the process of preempting the priority, and when the processing of the second context is completed and the priority is returned to the first context (S205), the stack restore a pointer

Meanwhile, referring to FIG. 3 , when the first task (Task 1) is input, the stack pointer is 0x700, when the second task (Task 2) is input, the stack pointer is increased to 0x780, and the second task (Task 2) ) ends and returns to the first task (Task 1), the increased stack pointer Ox780 is returned. Indicates the situation in which the returned stack fault occurs.

4 is a flowchart illustrating a process of identifying a cause of a stack defect based on a history previously recorded in the stack in FIG. 2 .

Referring to FIG. 4 , when a stack defect occurs (S301), the central processing unit 100 returns a previously stored stack history (eg, context and stack pointer values) (S302).

When the stack history (eg, the context and the stack pointer value) is returned as described above, the central processing unit 100 refers to this when abnormal contexts (ie, candidate contexts that cause a stack defect) are detected (S303). example), the cause of the stack defect (eg, the context causing the stack defect) is identified by analyzing the corresponding abnormal contexts (S304).

A method of determining the cause of the stack defect will be described in more detail with reference to FIG. 5 .

FIG. 5 is a flowchart for explaining a method of identifying a cause of a stack defect by additionally allocating a temporary stack area when a stack greater than or equal to a margin value for an initially set stack area size is used in FIG. 4 .

Referring to FIG. 5 , the central processing unit 100 sets a predetermined margin value (eg, the stack When the margin value designated as 80% with respect to the area size 100%) is reached (S401), a temporary stack area is dynamically additionally allocated (S402).

For example, assuming that the size of the stack area initially set in the application software is 10 (that is, 100%) and the preset margin value is 8 (ie, 80%), the stack usage during execution of the application software is When the margin value is 8 (ie, 80%) or more, the central processing unit 100 dynamically additionally allocates a temporary stack area (eg, 100% of the initially set stack area size). As described above, the temporary stack area is dynamically additionally allocated as the stack usage exceeding the margin value is detected, so that it is possible to prevent the occurrence of a stack defect during execution of the corresponding application software.

Therefore, when a new context is subsequently input (that is, when a new event using the stack occurs additionally), the central processing unit 100 dynamically compares the previously used stack area (eg 80%) in the initially set stack area. The total sum (eg 105%) of the additionally used stack region (eg 25%) in the temporary stack region (eg 100%) additionally allocated as In one case (Yes in S403), it alarms that a stack fault (error) has occurred and returns the stack history (eg, context and stack pointer values) (S405).

At this time, when a stack fault occurs, a situation in which the computing system is down or reset occurs, but in the present embodiment, only the occurrence of a stack fault error is alarmed, and a situation in which the computing system is down does not occur. That is, in the present embodiment, since the dynamically additionally allocated temporary stack area (eg, 100% of the initially set stack area size) is used, the stack defect becomes a recoverable error.

Accordingly, the central processing unit 10) checks whether to continue (execution) of the application software to the user through the user interface (UI) (S406), By repeating step S406, other additional causes of stack faults (eg, contexts that additionally generate stack faults) can be continuously identified. In addition, the central processing unit 10 removes the identified cause (eg, a context causing a stack fault) to the user by terminating the continuing process (execution) when the user does not select to proceed (No in S406). Allows you to perform tasks intended to be performed (eg, modifying the code of application software).

For example, through the analysis of the stack history (that is, through the analysis of the context and the stack pointer value included in the stack history), the central processing unit 10 abnormally increases and restores the stack pointer. It detects the failure and displays it through the user interface (UI). That is, it identifies which context required more stacks than the available stack size and displays it through the user interface (UI). Accordingly, the user can perform an operation (eg, modifying the code of the application software) to remove the identified cause (eg, the context that causes the stack fault).

As described above, in the present embodiment, when any application software is executed in a state in which the occurrence of a stack defect is prevented (eg, a state in which a temporary stack area is additionally allocated dynamically), when the stack defect becomes a state (that is, , when the sum of the stack area already used in the initially set stack area and the stack area additionally used in the dynamically additionally allocated temporary stack area exceeds the size of the initially set stack area), this state (i.e., stack fault) state that can occur), and the cause (that is, the cause of the stack fault) can be diagnosed or identified.

Meanwhile, in the above embodiment, the margin value is set for the initially set stack region size, but in another embodiment, the margin value may be set in a different way.

6 is another method of determining the cause of a stack defect by additionally allocating a temporary stack area when a shortage of the stack area is expected by comparing the maximum stack usage with the stack area currently remaining in the initially set stack area in FIG. It is an example diagram for explanation.

As shown in FIG. 6 , the central processing unit 10 records the maximum stack usage used whenever an event occurs during context switching. That is, out of the accumulated stack usage, the maximum usage of the stack used by the context is recorded.

In addition, the central processing unit 10 calculates the size of the stack area currently remaining in the initially set stack area.

In addition, the central processing unit 10 compares the size of the currently remaining stack area with the maximum usage of the stack used by the context so far, that is, the margin value specified for the maximum usage (ie, the required size) (eg 20%) If the combined capacity (i.e., required size + margin value) is larger than the size of the current remaining stack area (i.e., the remaining size), it is determined that additional dynamic stack area allocation is necessary and the temporary stack area is dynamically additionally allocated. .

For example, in the case of the first task Task1, when the maximum usage is 0x20 and the size of the currently remaining stack area is also 0x20, it is determined that additional dynamic stack allocation is required and the temporary stack area is dynamically additionally allocated. In the case of the second task Task2, when the maximum usage is 0x30 and the size of the current remaining stack area is 0x100, it is determined that additional dynamic stack allocation is not required. In the case of the third task (Task3), when the maximum usage is 0x100 and the size of the current remaining stack area is 0x110, it is determined that additional dynamic stack allocation is required and the temporary stack area is dynamically additionally allocated.

Accordingly, it is in a state in which the occurrence of a stack defect can be prevented while the corresponding application software is being executed.

Thereafter, in the same manner as described in FIG. 5 , the central processing unit 100 determines that the sum of the stack areas used in the temporary stack area dynamically additionally allocated to the initially set stack area exceeds the size of the initially set stack area. In this case, it alarms that a stack fault (error) has occurred and returns the stack history (eg, context and stack pointer values).

Accordingly, the central processing unit 10) allows the user to identify the cause (eg, the context in which the stack defect occurs) of the application software occurs to the user through the user interface (UI), thereby providing the user with the identified cause. Allows you to perform actions (eg, modifying code in application software) to eliminate (eg, contexts that cause stack faults).

As described above, in this embodiment, by recording the stack history (i.e., the stack usage history), it is possible to accurately analyze the cause when an error occurs. It has an effective effect, it can detect in advance whether a specific software function occupies an abnormally large stack, and also has the effect of enabling resolution without program damage even if a stack defect (error) occurs during software execution.

As described above, the present invention has been described with reference to the embodiment shown in the drawings, but this is merely exemplary, and various modifications and equivalent other embodiments are possible therefrom by those of ordinary skill in the art. will understand the point. Therefore, the technical protection scope of the present invention should be defined by the following claims. Also, the implementations described herein may be implemented as, for example, a method or process, an apparatus, a software program, a data stream, or a signal. Although discussed only in the context of a single form of implementation (eg, only as a method), implementations of the discussed features may also be implemented in other forms (eg, in an apparatus or a program). The apparatus may be implemented in suitable hardware, software and firmware, and the like. A method may be implemented in an apparatus such as, for example, a processor, which generally refers to a computer, a microprocessor, a processing device, including an integrated circuit or programmable logic device, or the like. Processors also include communication devices such as computers, cell phones, portable/personal digital assistants (“PDAs”) and other devices that facilitate communication of information between end-users.

100: central processing unit
200: memory unit
201: stack unit

Claims (16)

A method for diagnosing a cause of a stack fault in a computing system including a central processing unit and a stack memory, the method comprising:
detecting, by the central processing unit, occurrence of a stack defect in a process in which input and exit of a context are repeated according to the execution of application software;
returning, by the central processing unit, a stack history when the stack fault occurs; and
When the stack history is returned, determining, by the central processing unit, a context in which a stack fault occurs based on the stack history;
In the step of identifying a context that causes a stack fault based on the stack history,
The central processing unit,
A method for diagnosing a cause of a stack fault, characterized in that, when the stack pointer stored when a context is input and the stack pointer returned when the context is terminated and returned are different, the context causing the stack fault is identified.
The method of claim 1, wherein the stack history comprises:
A method for diagnosing the cause of a stack fault, comprising a context and a stack pointer value.
The method of claim 1 , wherein prior to the step of detecting the occurrence of the stack fault,
checking, by the central processing unit, whether the stack usage reaches a predetermined margin value with respect to an initially set stack area size in order to prevent the computing system from being down or reset when the stack fault occurs; and
and dynamically allocating a temporary stack area additionally when the stack usage reaches a predetermined margin value with respect to an initially set stack area size.
The method of claim 1 , wherein prior to the step of detecting the occurrence of the stack fault,
In order to prevent the computing system from being down or reset when the stack fault occurs, the central processing unit records the maximum stack usage each time an event occurs during context switching, and records the stack area currently remaining in the initially set stack area. calculating a size; and
The central processing unit compares the size of the currently remaining stack area with the maximum usage of the stack used by the context, and when the stack capacity obtained by adding the margin value specified to the maximum usage is larger than the size of the currently remaining stack area, additional dynamics The method of diagnosing a cause of a stack defect, further comprising: determining that allocation of a stack area is necessary and dynamically additionally allocating a temporary stack area.
According to claim 3 or 4, in the step of detecting the occurrence of the stack fault,
The central processing unit,
When the sum of the stack area already used in the initially set stack area and the stack area additionally used in the dynamically additionally allocated temporary stack area exceeds the size of the initially set stack area, a stack defect is detected A method for diagnosing the cause of a stack fault, characterized in that
delete The method of claim 1,
After identifying the context causing the stack fault,
The central processing unit,
The method of diagnosing a cause of a stack fault further comprising; displaying a context in which the stack fault occurs through a user interface.
The method of claim 7, wherein after displaying the context causing the stack fault through a user interface,
checking, by the central processing unit, whether the application software continues to the user through a user interface; and
The method of diagnosing a cause of a stack defect further comprising: when the user selects to continue, the central processing unit continues to execute the application software to continuously identify another context that causes the stack defect.
stack memory of the computing system; and
a central processing unit that detects the occurrence of a stack defect in the process of repeatedly entering and exiting the context according to the execution of the application software in the computing system; and
If the above stack fault occurs,
The central processing unit returns a stack history and analyzes the returned stack history to determine a context in which a stack fault occurs,
The central processing unit diagnoses the cause of a stack fault, characterized in that, when a stack pointer stored when a context is input and a stack pointer returned when the context is terminated and returned are different, it is determined as a context causing a stack fault. device to do.
10. The method of claim 9, wherein the stack history,
A device for diagnosing the cause of a stack fault, characterized in that it includes a context and a stack pointer value.
10. The method of claim 9, wherein the central processing unit,
In order to prevent the computing system from being down or reset when the stack fault occurs, before the step of detecting the occurrence of the stack fault, it is checked whether the stack usage reaches a predetermined margin value for the initially set stack area size,
The apparatus for diagnosing a cause of a stack defect, further comprising dynamically allocating a temporary stack area when the stack usage reaches a predetermined margin value with respect to an initially set stack area size.
10. The method of claim 9, wherein the central processing unit,
In order to prevent the computing system from being down or reset when the stack fault occurs, prior to the step of detecting the occurrence of the stack fault, the maximum stack usage used whenever an event occurs during context switching is recorded, and in the initially set stack area, the current Calculate the size of the remaining stack area,
Compares the size of the current remaining stack area with the maximum usage of the stack used by the context, and dynamically allocates a temporary stack area when the sum of the margin value specified for the maximum usage is larger than the size of the current remaining stack area. A device for diagnosing the cause of a stack fault, characterized in that.
According to claim 11 or 12, wherein the central processing unit,
When the sum of the stack area already used in the initially set stack area and the stack area additionally used in the dynamically additionally allocated temporary stack area exceeds the size of the initially set stack area, a stack defect is detected A device for diagnosing the cause of a stack fault, characterized in that.
delete 10. The method of claim 9, wherein the central processing unit,
If the context causing the stack fault is identified,
The apparatus for diagnosing a cause of a stack fault, characterized in that the context causing the stack fault is displayed through a user interface.
The method of claim 15, wherein the central processing unit,
After displaying the context causing the stack fault through the user interface, it is checked whether the application software continues to the user through the user interface,
A device for diagnosing the cause of a stack fault, characterized in that when the user selects to continue, the application software is continuously executed to continuously identify other contexts causing the stack fault.

Images