KR102545765B1 - Method and system for detecting memory errors - Google Patents

Abstract

A method and system for detecting memory errors caused by application programs running on a computer system are provided. An embodiment of the present disclosure extracts global variables and local variables of an application before execution of the application, stores the extracted global variables and local variables in an information tag storage unit, and static static variables are stored based on information of the stored global variables and local variables. Methods and computer systems for detecting memory errors and detecting dynamic memory errors collected during execution of an application are provided.

Description

Method and system for detecting memory errors {METHOD AND SYSTEM FOR DETECTING MEMORY ERRORS}

The present disclosure relates to a method and system for detecting memory errors caused by application programs running on a computer system. Specifically, the present disclosure relates to a method and system for detecting a memory crash error caused by an incorrect memory reference of an application program on a binary basis and analyzing the cause of the memory error.

The computer system executes the application program by recording execution information of the application program in a binary according to a predetermined standard, loading the corresponding binary into a memory, and then referring to (reading/writing) the memory. An application program running on a computer system may refer to an arbitrary memory area by performing a series of memory instructions provided by the system, and may cause a system error due to unintended memory reference.

The memory area used to run the application program on the computer system includes a static memory area that is fixed inside the application program even when the application program is running, and a dynamic memory area that is created/destroyed as needed while the application program is running. ) is divided into memory areas.

Conventional memory analysis techniques include a method of loading an application program with tools for detecting memory errors in advance at the time of compilation (Compile Time Instrumentation and Static Binary Instrumentation) and a method of loading a tool for detecting errors in advance just before application program execution (Dynamic Binary Instrumentation). Instrumentation) and a method (Dynamic Binary Injection) of loading a detection tool at an arbitrary point in time during execution of an application program.

In the conventional techniques for detecting memory errors by loading tools during program execution, since the memory detection tools are loaded after the application program is executed, dynamic memory errors that are accessed, allocated, and freed after the memory detection tools are loaded are analyzed. It is possible, but it is not possible to obtain information about global variables that have been allocated before application execution and local variables that are allocated to the stack. Memory errors are problems that cannot be detected.

In addition, even if a memory error occurs, the application program may continue to run in an unintended direction, and when the application program can no longer be executed, a system crash occurs and is terminated, but at the point of termination It is difficult to correct the program error because information about the cause of the memory error is unknown.

The present disclosure detects defects in dynamic memory by extracting global variables and local variables before execution of an application program and detecting memory errors using the extracted global variables and local variables, as well as memory errors in global and stack areas. An object of the present invention is to provide a method and system capable of detecting errors together.

In addition, the present disclosure collects memory information at the time when an application program crashes and memory defect information before a crash occurs by replacing a signal handler of a kernel with a signal handler that monitors memory defect information. It is an object to provide a method and system that facilitates analysis of the causes of memory errors.

In order to solve the above-described technical problem, an embodiment of the present disclosure extracts global variable and local variable information of the application before execution of the application; storing the extracted global variable and local variable information in an information tag repository; and detecting a memory error based on the global variable and the local variable information stored in the information tag storage unit and dynamic memory information collected while the application is running. Provides a way to detect errors.

For example, in the step of extracting global variable and local variable information, a binary analyzer for extracting static memory information of the application is set to be executed before the application is executed according to a user input, and the binary analyzer is configured to perform the binary analyzer. Global and local variables of the application can be extracted.

For example, the extracting of global variable and local variable information may include analyzing at least one of an address, a size, and a call function of each of the extracted global and local variables.

For example, the detecting of the memory error includes monitoring the dynamic memory information that is dynamically allocated, accessed, and released from a heap area of memory by the running application through a dynamic binary injection (DBI) technique. can do.

For example, the detecting of the memory error may detect a memory defect in at least one of a global area, a stack area, and a heap area of the memory.

For example, in the method, according to a signal that a crash occurs in an application and the application is terminated, a signal handler of a kernel receives memory information at the time when the crash occurs and the occurrence of the crash. A step of replacing previous memory defect information with a signal handler that monitors may be further included.

For example, the method may include calling a replaced signal handler; and collecting call stack information of an application related to the crash using the called signal handler.

For example, in the detecting of the memory error, the cause of the memory error may be analyzed based on memory defect information in a global area, a stack area, and a heap area of memory and the collected call stack information.

For example, the method may further include outputting a memory error analysis result.

In order to solve the above technical problem, an embodiment of the present disclosure is a memory; And a processor for detecting a memory error generated as an application executed by the computer system refers to the memory, wherein the processor determines global variables and local variables of the application before execution of the application ( A binary analysis module that extracts local variable) information; a defect detection module configured to detect a defect of the memory based on the extracted global variable and local variable information; and a defect analysis module configured to detect the memory error based on the detected memory defect and to analyze the detected error.

For example, the binary analysis module sets a binary analyzer for extracting global variables and local variables of the application to be executed before the application is executed according to a user input, and sets the global variables and local variables of the application to be executed through the binary analyzer. variables can be extracted.

For example, the computer system may further include a storage unit for storing extracted static memory information, and the defect detection module may detect a defect in the memory based on the global variable and local variable information stored in the storage unit. can

For example, the defect detection module analyzes at least one of an address, a size, and a call function of each of the extracted global variable and the local variable, and obtains information about the memory defect based on the analysis result. can

For example, the defect detection module may monitor dynamic memory information that is dynamically allocated, accessed, and released from a heap area of the memory while the application is running using a dynamic binary injection (DBI) technique.

For example, the defect detection module may detect a memory defect in at least one of a global area, a stack area, and the heap area of the memory.

For example, the processor may further include a crash monitoring module that collects data related to the crash by analyzing a crash occurring while the application is running.

For example, the crash monitoring module transmits a signal handler of a kernel according to a signal that a crash occurs in the application and the application is terminated, memory information at the time when the crash occurs and occurrence of the crash It can be replaced with a signal handler that monitors previous memory defect information.

For example, the crash monitoring module may call the replaced signal handler and collect call stack information of an application related to the crash using the called signal handler.

For example, the defect analysis module may perform the memory error based on memory defect information in the global area, stack area, and heap area of the memory detected by the defect detection module and the call stack information collected by the crash monitoring module. causes can be analyzed.

In order to solve the above technical problem, an embodiment of the present disclosure provides a computer program product including a computer-readable storage medium, wherein the storage medium is a global variable (global variable) of the application before execution of the application. ) and extracting local variable information; storing the extracted global variable and local variable information in an information tag repository; and instructions for performing a step of detecting a memory error based on the global variable and the local variable information stored in the information tag storage unit and dynamic memory information collected while the application is running. can do.

A method and system according to an embodiment of the present disclosure is directed to memory errors caused by global and stack areas of memory as well as memory errors that occur when an application program dynamically allocates, accesses, and frees a memory of a computer system. Since it is also possible to detect errors, the accuracy of memory error detection can be improved. In addition, the method and system according to an embodiment of the present disclosure, when an application program crashes, outputs a result of monitoring memory information at the time of the crash and memory defect information until before the crash, so that the user can receive a memory error. can accurately determine the cause of

This disclosure may be readily understood in combination with the detailed description that follows and the accompanying drawings, wherein reference numerals denote structural elements.
1 is a block diagram illustrating components of a computer system according to an embodiment of the present disclosure.
2 is a flowchart illustrating a method of detecting a memory error by a computer system according to an embodiment of the present disclosure.
3 is a conceptual diagram illustrating the structure of an ELF file, which is an execution file of an application program.
4 is a diagram showing an example of program code used to extract information of global variables of an application program.
5 is a diagram showing an example of program codes used to extract information of local variables of an application program.
6 is a diagram illustrating memory information stored in an information tag.
7 is a block diagram illustrating components of a memory error detection system according to an embodiment of the present disclosure.
8 is a flowchart illustrating a method of detecting a memory defect in at least one of a global area, a stack area, and a heap area of a memory by a computer system according to an embodiment of the present disclosure.
9 is a flowchart illustrating a method of detecting and analyzing a cause of an error in a dynamic memory area by replacing a signal handler by a computer system according to an embodiment of the present disclosure.
10 is a flowchart illustrating a method for a computer system to detect a memory error due to an application program according to an embodiment of the present disclosure.
11A is a diagram showing an example of a program code for analyzing a memory error due to a release defect of an unallocated pointer, and FIG. 11B is a diagram illustrating memory information stored in an information tag storage unit.

The terms used in the embodiments of this specification have been selected from general terms that are currently widely used as much as possible while considering the functions of the present disclosure, but they may vary depending on the intention or precedent of a person skilled in the art, the emergence of new technologies, and the like. . In addition, in a specific case, there is also a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the description of the corresponding embodiment. Therefore, the term used in this specification should be defined based on the meaning of the term and the overall content of the present disclosure, not a simple name of the term.

Singular expressions may include plural expressions unless the context clearly dictates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by one of ordinary skill in the art described herein.

When it is said that a certain part "includes" a certain component throughout the specification, it means that it may further include other components without excluding other components unless otherwise stated. In addition, terms such as "...unit" and "...module" described in the specification mean a unit that processes at least one function or operation, which is implemented as hardware or software or a combination of hardware and software. It can be.

The expression “configured to (or configured to)” as used herein means depending on the situation, for example, “suitable for”, “having the capacity to” ", "designed to", "adapted to", "made to", or "capable of" can be used interchangeably. The term "configured (or set) to" may not necessarily mean only "specifically designed to" hardware. Instead, in some contexts, the phrase "a system configured to" may mean that the system "is capable of" in conjunction with other devices or components. For example, the phrase "a processor configured (or configured) to perform A, B, and C" may include a dedicated processor (e.g., an embedded processor) to perform those operations, or by executing one or more software programs stored in memory; It may mean a general-purpose processor (eg, CPU or application processor) capable of performing corresponding operations.

In the present disclosure, a "computer system" includes, for example, a desktop personal computer (PC), a laptop personal computer (laptop PC), a netbook computer, a workstation, a server, and a personal digital assistant (PDA). etc., but is not limited thereto. In one embodiment of the present disclosure, the computer system is a smartphone, a tablet personal computer (tablet PC), a mobile phone, a video phone, an e-book reader, a portable multimedia player (PMP) ), an MP3 player, a mobile medical device, a camera, an automobile electronic control device, or a wearable device.

In the present disclosure, "application program" means a computer program that runs on an operating system (OS) of a computer system, and will be referred to as "application" hereinafter for simplicity and clarity of expression. .

Hereinafter, with reference to the accompanying drawings, embodiments of the present disclosure will be described in detail so that those skilled in the art can easily carry out the present disclosure. However, the present disclosure may be implemented in many different forms and is not limited to the embodiments described herein.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

1 is a block diagram showing components of a computer system 100 according to an embodiment of the present disclosure.

Referring to FIG. 1 , a computer system 100 may include a processor 110, a memory 120, and a storage unit 130. The computer system 100 may omit at least one of the components shown in FIG. 1 or may additionally include other components. In one embodiment, computer system 100 electrically connects processor 110, memory 120, and storage 130 to each other and communicates between the components (eg, control messages and/or data). ) may be further included.

The processor 110 is a general-purpose processor that loads computer-readable instructions or data stored in the memory 120 and executes at least one software program according to the loaded instructions or data. processor). The processor 110 may include, for example, at least one of a central processing unit (CPU), an application processor (AP), and a communication processor (CP), but is not limited thereto. no. In one embodiment, the processor 110 may be composed of any one of an application-specific integrated circuit (ASIC) chip, field-programmable gate arrays (FPGA), and a programmable-logic device.

The processor 110 is injected into the analysis tool 110-1 for detecting and analyzing errors in the memory 120 and each process of an application running on the computer system 100, It may include an agent (agent) 110-2 that monitors defect detection and application crashes.

The analysis tool 110 - 1 may include a binary analysis module 112 and a defect analysis module 114 . Agent 110 - 2 may include a fault detection module 116 and a crash monitoring module 118 . Here, "module" may mean a unit including any one or a combination of hardware and software. A “module” may be replaced with a term such as, for example, a unit, logic, logical block, component, or circuit. A “module” may be a minimal unit or part thereof that performs one or more functions. In FIG. 1 , the binary analysis module 112 , the defect analysis module 114 , the defect detection module 116 , and the crash monitoring module 118 are shown as being separated from each other, but are not limited thereto. In one embodiment, the binary analysis module 112, fault analysis module 114, fault detection module 116, and crash monitoring module 118 may be integrated into one module or a plurality of modules of three or less.

The binary analysis module 112 may extract static memory information including global variables and local variables of applications executed by the computer system 100 . In one embodiment, the binary analysis module 112 may extract global variables and local variables of the application in advance before the application is executed on the computer system 100 . The binary analysis module 112 may first execute a binary analyzer that extracts global variables and local variables of the application before the application is executed through user input. In one embodiment, the binary analysis module 112 may be set to run the binary analyzer by default.

The binary analysis module 112 may extract global variables and local variables by analyzing the code of the ELF file of the application. The binary analysis module 112 may store the extracted global variables and local variables in the storage unit 130 . In one embodiment, the binary analysis module 112 may extract global variables and local variables by analyzing the code of the Windows PE file. A specific method for the binary analysis module 112 to extract the global and local variables of the application and store them in the storage unit 130 will be described in detail in the description of FIGS. 3 to 6 .

The defect detection module 116 may detect defects in the memory 120 based on global variable and local variable information extracted by the binary analysis module 112 and stored in the storage 130 . In one embodiment, the defect detection module 116 analyzes at least one of an address, a size, and a call function of each of the global and local variables of the extracted application, and the defect of the memory 120 based on the analysis result. information can be obtained.

The defect detection module 116 may monitor dynamic memory information that is dynamically allocated, accessed, and released from the heap area of the memory 120 while an application is running using Dynamic Binary Injection (DBI) technology. In one embodiment, the defect detection module 116 detects memory defects in the global area and the stack area of the memory 120 based on the global and local variables stored in the storage unit 130, and uses DBI technology. It is possible to detect a memory defect by monitoring function calls in the heap area of the memory 120. Local variables may be stored in the stack area.

The defect detection module 116 may detect defects in the memory using memory address information stored in the storage unit 130 when functions related to allocation, access, and release of memory are executed. For example, the defect detection module 116 determines whether the value of a parameter corresponding to an allocation size among parameters of a memory allocation function is '0' (zero-size memory allocation), and when the execution result of the memory allocation function is NULL ( It may be determined that there is a defect related to memory allocation in the case of at least one of a memory allocation failure) and a case in which there is dynamic memory allocation that is not freed after the application is terminated (memory leak).

In addition, the defect detection module 116 detects when the address parameter value of the memory access function is NULL (NULL pointer access), when the release flag value of the information tag for the pointer to be accessed is set (released pointer access), When the information tag for the pointer to be accessed does not exist and does not correspond to the stack address space (unallocated pointer access), when the information tag for the pointer to be accessed is out of the range of the allocation size (out of the allocation range) access), and when '\0' is not processed in the string corresponding to the source of the string function (collision with the memory space of other variables), it is determined that there is a defect related to memory access. can do.

In addition, the defect detection module 116 is used when the parameter value of the memory release function is NULL (NULL pointer release), when the information tag does not exist in the storage unit 130, or when the value of the allocation flag corresponds to static allocation ( unallocated pointer release), when the allocation function type flag value of the information tag does not match the release function type (allocation/release mismatch), and when the release flag on the information tag in the storage unit 130 is set (release It can be determined that there is a defect related to memory release in at least one of the above).

The crash monitoring module 118 may collect data related to crashes by analyzing crashes caused by incorrectly allocating, accessing, or releasing the memory 120 while the application is running. The crash monitoring module 118 may hook a signal to monitor the crash when an application crashes. In one embodiment, the crash monitoring module 118 sends a signal handler of a kernel to the memory information at the time of the crash and the crash according to the signal that the application crashes and the application is terminated. It can be replaced with a signal handler that monitors memory defect information prior to the occurrence of The crash monitoring module 118 may call the replaced signal handler and collect call stack information of an application related to the crash using the called signal handler. The crash monitoring module 118 may store the collected call stack information in the storage unit 130 .

The defect analysis module 114 may output defect information of the memory 120 by analyzing log information obtained from the agent 110-2. In one embodiment, the fault analysis module 114 includes memory defect information in the global area, stack area, and heap area of the memory 120 detected by the fault detection module 116 and calls collected by the crash monitoring module 118. An error cause of the memory 120 may be analyzed based on the stack information. The defect analysis module 114 may analyze the location where the memory error occurred or the cause of the memory error including memory setting, buffer error, reference address error, and the like. The defect analysis module 114 may output the analyzed result in text form.

The memory 120 may store instructions or data related to at least one component of the computer system 100 . The memory 120 may include, for example, dynamic RAM (DRAM), static RAM (SRAM), or synchronous dynamic RAM (SDRAM), but is not limited thereto.

In one embodiment, memory 120 may include non-volatile memory that stores software and/or programs. A program may include, for example, a kernel, a library, and an application, but is not limited thereto. Middleware and API (Application Programming Interface) may be stored in the memory 120 .

The storage unit 130 may store memory error information detected by the processor 110 . The storage unit 130 may be configured with any one of a flash memory (eg, NAND flash or NOR flash), a hard drive, and a solid state drive (SSD). However, the storage unit 130 is not limited to being composed of the listed examples.

The storage unit 130 may include an information tag repository for storing static memory information including global variables and local variables of the application extracted by the binary analysis module 112 . In one embodiment, the storage unit 130 may store defect information in the heap area of the memory 120 analyzed by the defect detection module 116 in a log form. In one embodiment, the storage unit 130 may store the call stack information collected by the crash monitoring module 118 in the form of an application crash log, and store data obtained by analyzing crashes generated in the kernel itself as a kernel crash log. . This will be described in detail in the description of FIG. 10 .

2 is a flowchart illustrating a method for the computer system 100 to detect a memory error according to an embodiment of the present disclosure.

In step S210, the computer system 100 extracts global variables and local variables of the application before execution of the application. In one embodiment, the computer system 100 sets a binary analyzer that extracts global variables and local variables of the application to be executed first before the application is executed according to a user input, and analyzes the application through the executed binary analyzer. Global and local variables can be extracted. In one embodiment, the computer system 100 may extract global and local variables of the application by analyzing the code of the ELF file of the application. In one embodiment, the computer system 100 may analyze at least one of an address, a size, and a call function of each of the extracted global variable and local variable.

In step S220, the computer system 100 stores the global and local variables of the extracted application in an information tag repository. Information tagging is information on global and local variables (address, size) and dynamically allocated, accessed, and deallocated heap area information (address, size, allocation function call stack, release function call stack, allocation function type) in memory space. This will be described in detail in the description of FIG. 6 .

In step S230, the computer system 100 detects a memory error based on the stored global variable and local variable information and dynamic memory information collected during execution of the application. In one embodiment, the computer system 100 may detect a defect in a static memory area based on global variable and local variable information of an application stored in the information tag storage unit.

The computer system 100 may also monitor dynamic memory information that is dynamically allocated, accessed, and released from a heap area of memory while an application is running using a dynamic binary injection (DBI) technique. That is, the computer system 100 detects memory defects in the global area and the stack area of the memory based on the global and local variables stored in the information tag storage unit, and in the heap area of the memory using DBI technology. Memory defects can be detected by monitoring function calls.

In one embodiment, the computer system 100 may hook a signal to monitor the crash when a crash occurs due to memory corruption or the like while an application is running. The computer system 100 may monitor memory information at the time of application crash and memory defect information prior to the crash, and collect call stack information related to the crash.

The computer system 100 includes defect information in a static memory area due to global and local variables of the application stored in the information tag storage unit, defect information in a dynamic memory area that is dynamically allocated, accessed, and freed during application execution, and call Based on the stack information, a memory error can be detected and the cause of the error can be analyzed. In one embodiment, the computer system 100 may output analysis results in text form.

Conventional technologies for detecting memory errors can analyze dynamic memory errors that are accessed, allocated, and freed after the memory detection tool is loaded because the memory detection tool is loaded at the time of application execution, but allocated before application execution. There is a problem in that memory errors occurring in the global and stack areas of memory cannot be detected because information cannot be obtained about the completed global variables and local variables allocated to the stack area. In addition, even if a memory error occurs in the system, the application may continue to run in an unintended direction, and if the application crashes and is terminated, information about the cause of the memory error is not known at the time of termination, resulting in program errors. It was difficult to correct.

The computer system and memory error detection method according to the embodiment shown in FIGS. 1 and 2 not only detects errors due to dynamic memory information that is dynamically allocated, accessed, and freed due to application execution, but also detects errors before the application is executed. Accuracy of memory error detection may be improved by extracting static memory information such as global variables and local variables of an application in advance and detecting memory errors using the extracted static memory information. In addition, a computer system and memory error detection method according to an embodiment of the present disclosure, when an application crashes, analyzes the result of monitoring memory information at the time of the crash and memory defect information until before the crash, By outputting the analyzed result, the user can accurately determine the cause of the memory error.

In addition, the computer system and memory error detection method according to an embodiment of the present disclosure is efficient because it does not require additional cost and space because it is possible to detect defects and analyze errors in a memory using a software method without adding additional hardware equipment. . In addition, since the conventional DBI (Dynamic Binary Injection) technique is used, it is not necessary to change the execution binary.

3 is a conceptual diagram showing the structure of an ELF file 300, which is an execution file of an application, and FIG. 4 is a diagram showing an example of a program code 400 used to extract global variable information of an application.

Referring to FIG. 3, the ELF file 300, which is an executable file used in Linux or UNIX, includes a text area 310, which is an area for loading application execution commands, and variables necessary for executing the application. A stored data area 320 and an uninitialized data area BSS area 330 may be included. Initialized variables are stored in the data area 320 and may reside in memory until the application is terminated.

Global variables are stored in the data area 320 and the BSS area 330 . The computer system can extract addresses and sizes from global variable information stored in the data area 320 and the BSS area 330 of the ELF file 300 . In one embodiment, if the computer system is based on Windows, global variable information may be extracted through a PE file, which is an executable file format of Windows.

The binary analysis module 112 (see FIG. 1 ) of the computer system may extract global variable information from the ELF file according to the program code 400 shown in FIG. 4 . 4 illustrates an example of a program code 400 for extracting global variables of an application, and embodiments of the present disclosure are not limited to the program code shown. The binary analysis module 112 creates a global variable called buffer 410 like the program code 400, analyzes the ELF header, and analyzes the BSS area 330 of the ELF file 300 (see FIG. 3). 3) global variable address and size information can be extracted.

5 is a diagram showing an example of program code 500 used to extract information of a local variable of an application.

The binary analysis module 112 (see FIG. 1) of the computer system extracts the local variable 520 by analyzing the executable code 510 stored in the text area (.text area) of the ELF file according to the program code 500. can 5 illustrates an example of a program code 500 for extracting global variables of an application, and embodiments of the present disclosure are not limited to the program code shown.

According to the program code 500, when the main function is executed, an operation of adding or deleting a value to a stack pointer (SP) may be performed. The binary analysis module 112 analyzes a stack pointer addition or deletion operation of the program code 500 to extract local variable information including at least one of the address, size, and call function of the local variable 520. can Here, since the address of the stack is changed during application execution, the address of the local variable can be extracted as an offset value of the stack pointer.

6 is a diagram illustrating memory information stored in an information tag 600 .

Referring to FIG. 6 , an information tag 600 includes an address 610, a size 620, an allocation flag 630, an allocation function type 640, a release flag 650, and an allocation of a static memory area and a dynamic memory area. Information on the caller 660 and the release caller 670 may be included. In the address 610 and size 620 of the information tag 600, information about the address and size of the heap memory area as well as the address and size of each of the global and local variables of the application may be stored.

A general information tag stores only basic information (eg, address, size, etc.) for a specific memory area. However, the information tag 600 according to an embodiment of the present disclosure adds additional information such as an allocation caller 660 and a release caller 670 in the heap memory area to facilitate analysis of the cause of a memory error. Can be configured to save.

The computer system 100 may detect an error in the static memory area by referring to the address 610 and size 620 of each of the global variable and the local variable stored in the information tag 600 . In addition, the computer system 100 may detect errors in the dynamic memory area by monitoring call information of functions that are dynamically allocated, accessed, and deallocated in the heap memory area using the information tag 600 .

7 is a block diagram illustrating components of a memory error detection system 700 according to an embodiment of the present disclosure. The memory error detection system 700 is a system for detecting a memory error occurring in a computer system and analyzing the cause of the memory error, and may be implemented by a processor 110 (see FIG. 1 ). However, it is not limited thereto, and the memory error detection system 700 may be implemented through a combination of hardware and software. The memory error detection system 700 may include at least one of a module, a program, a routine, a set of instructions, and a process for performing at least one or more functions.

Referring to FIG. 7 , a memory error detection system 700 may include an application 702 , a library 704 , a device driver 706 , and an operating system 708 .

The application 702 may include a disassembler 712 , a binary analyzer 714 , a memory defect monitor 716 , and at least one process P ₁ to P _n . The disassembler 712 may provide information on binary files such as the library 704, a compiled object module, a shared object file, or an independent executable file, and express the ELF file in assembly language. Also, in one embodiment, the disassembler 712 may disassemble PE files in the Windows operating system and provide information on binary files. For example, the disassembler 712 may be implemented as a program such as Objdump, but is not limited thereto.

The binary analyzer 714 may be configured to extract global and local variables of an application before the application is executed according to user input. The binary analysis module 710 disassembles the ELF file, which is an executable file of the application, using the disassembler 712 and transfers the disassembled file to the binary analyzer 714. Information about the address and size of each variable can be extracted. In one embodiment, the binary analyzer 714 may be set to default so that it is pre-activated prior to execution of the application. The binary analysis module 710 may store information about addresses and sizes of extracted global variables and local variables in the information tag storage unit 734 . The binary analysis module 710 performs the same function as the binary analysis module 112 shown in FIG. 1, and duplicate descriptions will be omitted.

The memory defect monitor 716 may analyze a cause of a memory error by analyzing function call relationships during application execution and analyzing a trace log and a crash log. The trace log and the crash log will be described in detail in the description of FIG. 10 .

In one embodiment, memory defect monitor 716 may be operated by defect analysis module 720 . The memory defect monitor 716 may analyze defect information in the global area and the stack area of the memory based on global variable and local variable information stored in the information tag storage unit 734 . In addition, the memory defect monitor 716 may analyze dynamic memory defect information through call stack information collected based on function call information allocated, accessed, and released in the heap area of memory during application execution. there is. The memory defect monitor 716 may analyze the location where the memory error occurred or the cause of the memory error including memory setting, buffer error, reference address error, and the like.

A process may refer to a unit of an application executed on a computer system. For example, it may mean one execution window of a document writing application program. Application 702 can include at least one process P ₁ to P _n .

The library 704 may provide functions commonly required by at least one process P ₁ to P _n . The library 704 may perform, for example, functions related to input/output management, memory management, or function calls of at least one process (P ₁ to P _n ).

The library 704 may include a monitoring library (MMonitor.so) 732 and a user part 742 . The monitoring library 732 is called as the process (P ₁ to P _n ) is executed, and can track function call information allocated, accessed, and released from the heap area of memory by the process. In one embodiment, monitoring library 732 may be called by fault detection module 730 . In an embodiment, the defect detection module 730 may store, in the information tag storage unit 734, function call information allocated, accessed, and released in a heap area of memory. Here, the defect detection module 730 performs the same function as the defect detection module 116 shown in FIG. 1 except that it includes the information tag storage unit 734, and redundant descriptions are omitted. do it with

The user unit 742 may perform a function of controlling the device driver 706 . In one embodiment, when a crash occurs in any one of the at least one process (P ₁ to P _n ), the user unit 742 calls a call stack under the control of the kernel unit 744. ) information can be collected. This will be described in detail in the description of FIG. 10 .

The device driver 706 may include a kernel portion 744 . The kernel unit 744 may monitor the overall status of the memory including the global area, the stack area, and the heap area of the memory and the status of system resources. The kernel unit 744 may collect kernel crash information when a crash occurs in the kernel and store the collected kernel crash information in a log form.

In one embodiment, user part 742 and kernel part 744 may be operated by crash monitoring module 740 . The crash monitoring module 740 performs the same function as the crash monitoring module 118 shown in FIG. 1, and thus, duplicate descriptions will be omitted.

The operating system 708 may be any one of Linux, UNIX, and Windows, but is not limited to the listed examples.

8 is a flowchart illustrating a method of detecting a memory defect in at least one of a global area, a stack area, and a heap area of a memory by a computer system according to an embodiment of the present disclosure.

In step S810, the computer system extracts global variables and local variables of the application. In one embodiment, the computer system first sets a binary analyzer that extracts global variables and local variables of the application to be executed before the application is executed, and extracts the global variables and local variables of the application through the executed binary analyzer. can do. In one embodiment, the computer system may analyze the code of the ELF file of the application to extract at least one of the address, size, and call function of each of the global variable and the local variable of the application.

In one embodiment, the computer system may store the extracted global variables and local variables in an information tag repository.

At step S820, the computer system runs the application. The application may be executed according to a user's execution instruction being input. When one application is executed, the computer system can recognize it as one process. That is, a process may mean a unit of an application executed on a computer system. For example, it may mean one execution window of a document writing application program.

In step S830, the computer system monitors dynamic memory information that is dynamically allocated, accessed, and deallocated in the heap area of memory. In one embodiment, the computer system calls MMonitoring.so from the library as soon as the process is performed by the application executed in step S820, and allocates, accesses, and frees the heap area of memory using the called MMonitoring.so. You can trace function call information. In one embodiment, a computer system may monitor dynamic memory information that is dynamically allocated, accessed, and released from a heap area of a memory during process execution by using a dynamic binary injection (DBI) technique.

In step S840, the computer system detects a memory defect in at least one of the global area, the stack area, and the heap area of the memory. In one embodiment, the computer system may detect a defect in the global area and the stack area based on at least one of an address, a size, and a call function of each of a global variable and a local variable of an application stored in the information tag storage unit. In one embodiment, the computer system may detect defects in the dynamic memory area by monitoring function calls in the heap area of memory using the DBI technique.

9 is a flowchart illustrating a method of detecting and analyzing a cause of an error in a dynamic memory area by replacing a signal handler by a computer system according to an embodiment of the present disclosure.

In step S910, the computer system replaces a signal handler of a kernel with a signal handler that monitors the occurrence of a crash by an application. In one embodiment, the computer system may request the kernel to replace the signal handler in advance before the application is executed in user mode. In this case, the kernel can replace the preset signal handler with a signal handler that monitors memory information at the time when the application crashes and memory defect information until before the crash occurs.

In step S920, the computer system calls the replaced signal handler. When a crash occurs due to memory corruption or the like during a process operation by an application running on the computer system, the signal handler replaced in step S910 is called in the kernel instead. That is, the kernel can call the replaced signal handler in response to a signal that a process has crashed.

In step S930, the computer system collects call stack information. In one embodiment, the computer system may use a signal handler called from the kernel to collect call stack information capable of analyzing information related to a crash occurring in a process. The call stack information may refer to history of function calls for allocating, accessing, or releasing variables in memory by a process.

In step S940, the computer system analyzes the cause of the memory error based on the collected call stack information. In one embodiment, the computer system may analyze the cause of the memory error, including an error occurrence location in a dynamic memory area, a memory setting, a buffer error, a reference address error, and the like, based on the collected call stack information.

In one embodiment, the computer system may store memory error cause information acquired through call stack information as an application crash log.

10 is a flowchart illustrating a method for a computer system to detect a memory error due to an application according to an embodiment of the present disclosure. Referring to FIG. 10 , an error detection mode of a computer system includes a user mode 1001 that executes an application and detects a memory error by the executed application, and system resources used to execute an operation or function implemented in the application. A kernel mode 1002 for controlling/managing may be included. The kernel mode may be a mode operated in an operating system such as Linux or UNIX. However, the operating system in which the kernel mode operates is not limited to Linux or Unix.

In step S1011, the computer system extracts global variables and local variables of the application. In one embodiment, the computer system may first execute a binary analyzer that extracts global variables and local variables of the application before the application is executed, and extracts the global variables and local variables of the application through the executed binary analyzer. In one embodiment, the computer system may analyze the code of the ELF file of the application to analyze at least one of the address, size, and call function of each of the global variable and the local variable of the application.

In step S1012, the computer system stores the global and local variables of the extracted application in the information tag repository 1050. The information tag storage unit 1050 may store information about addresses and sizes of global variables and local variables, respectively. Steps S1011 and S1012 may be performed by the binary analysis module 1010. The binary analysis module 1010 performs the same function as the binary analysis module 112 shown in FIG. 1, and duplicate descriptions will be omitted.

In step S1013, the computer system injects a crash monitoring module into a kernel.

In step S1014, the computer system requests the kernel to replace the signal handler, and in step S1041, the kernel replaces the signal handler. In one embodiment, the user mode 1001 may request the kernel to replace a signal handler of the kernel with a signal handler that monitors the occurrence of a crash by an application. The signal handler replacement request in the user mode 1001 may be performed before the application execution step (S1015). That is, the computer system may request the kernel to replace the signal handler in advance before the application is executed in the user mode 1001 .

In this case, the kernel may replace the preset signal handler with a signal handler that monitors memory information at the time the application crashes and memory defect information until before the crash occurs (step S1041).

In step S1015, the computer system runs the application. The application may be executed according to a user's execution instruction input in the user mode 1001 . When one application is executed, the computer system can recognize it as one process. That is, a process may mean a unit of an application executed on a computer system.

In step S1031, the computer system collects call information of allocation, release, and access functions of a dynamic memory area through a dynamic binary injection (DBI) method. In one embodiment, the computer system calls MMonitoring.so from the library as soon as the application is executed in the user mode 1001, and calls functions that allocate, access, and deallocate the heap area of memory using the called MMonitoring.so. information can be traced. In one embodiment, the computer system may store function call information in the information tag storage 1050 . In this case, the information tag storage unit 1050 stores not only static memory information including global and local variables, but also dynamically allocated, accessed, and released heap area information (eg, address, size, and allocation function call stack). , free function call stack, allocation function type).

In step S1032, the computer system detects memory defects in the global area, the stack area, and the Heap area. In one embodiment, the computer system may use the DBI method to monitor dynamic memory information that is dynamically allocated, accessed, and deallocated in a heap area of memory by execution of an application, and detect a memory defect in the heap area.

In one embodiment, the computer system detects defects in the global area and the stack area based on at least one of the address, size, and call function of each of the global variable and the local variable of the application stored in the information tag storage unit 1050. can

When functions related to memory allocation, access, and release are executed, the computer system may detect defects in the memory using memory address information or size information stored in the information tag storage unit 1050 . For example, in a computer system, when the value of the parameter corresponding to the allocation size among the parameters of the memory allocation function is '0' (zero-size memory allocation), when the execution result of the memory allocation function is NULL (memory allocation failure) It may be determined that there is a defect related to memory allocation in the case of at least one of , and a case in which there is dynamic memory allocation that is not freed after the application is terminated (memory leak).

In addition, the computer system sets the pointer to be accessed when the address parameter value of the memory access function is NULL (NULL pointer access), when the release flag value of the information tag for the pointer to be accessed is set (released pointer access) If the information tag for does not exist and does not correspond to the stack address space (unallocated pointer access), if the information tag for the pointer to be accessed is out of the range of the allocation size (out of allocation range access), and It can be determined that there is a defect related to memory access in at least one case among cases where '\0' is not processed in the string corresponding to the source of the string function (collision with memory space of other variables).

In addition, the computer system is configured when the parameter value of the memory release function is NULL (NULL pointer release), when the information tag does not exist in the information tag storage unit 1050, or when the value of the allocation flag corresponds to static allocation (not allocated). pointer free), when the allocation function type flag value of the information tag does not match the type of the free function (allocation/freeing mismatch), and when the freeing flag is set in the information tag (freed memory freeing). In the case of , it can be determined that there is a defect related to memory release.

In step S1033, the computer system stores the detected memory defect information in the trace log 1060 and terminates the application. The trace log 1060 may store memory defect information in the global and stack areas of the memory as well as in the heap area.

Steps S1031 to S1033 may be performed by the defect detection module 1030 . The defect detection module 1030 performs the same function as the defect detection module 116 shown in FIG. 1, and duplicate descriptions thereof will be omitted.

In step S1042, the computer system calls the signal handler replaced in kernel mode 1002. The kernel mode 1002 may call the signal handler replaced in step S1041 according to a signal that a crash has occurred in the application due to memory corruption or the like in the application executed in the user mode 1001. there is.

In step S1043, the computer system collects call stack information. In one embodiment, a computer system may use a signal handler called in kernel mode 1002 to collect call stack information that can analyze information related to a crash that has occurred in an application. The call stack information may refer to history of function calls for allocating, accessing, or releasing variables in memory by an application.

In step S1044, the computer system stores the collected call stack information in an application crash log 1071. The application crash log 1071 may store call stack information related to a crash caused by an application executed in the user mode 1001 .

In step S1045, the kernel collects analysis data related to crashes that have occurred within the kernel itself. A crash that occurs in the kernel itself can occur when an application requests memory resources from the kernel and the request cannot be performed by the kernel. For example, a crash may occur in the kernel when an application tries to access system memory or allocates a variable exceeding the size of the variable. In the kernel mode 1002, kernel state information related to a crash, eg, current state information of the entire memory including the global area, stack area, and heap area, or information related to the resource status of the system may be collected.

In step S1046, the computer system stores the crash analysis data in a kernel crash log 1072 and ends. The kernel crash log 1072 may store crash information related to the kernel, that is, state information of the entire memory at the time of collection or information related to the resource status of the system. What ends in step S1046 is the kernel itself, which is different from steps S1033 and S1044 in which applications end.

Steps S1041 to S1046 may be performed by the crash monitoring module 1040. The crash monitoring module 1040 performs the same function as that of the crash monitoring module 118 shown in FIG. 1, and duplicate descriptions will be omitted.

In step S1021, the computer system analyzes the cause of the memory error based on the information stored in the trace log 1060 and the application crash log 1071. In one embodiment, the computer system provides static static information through memory defect information in the global, stack, and heap areas of memory stored in the trace log 1060 and call stack information stored in the application crash log 1071. And the cause of error in dynamic memory can be analyzed. In one embodiment, the computer system may analyze the cause of the memory error, such as a memory error occurrence location, memory setting, buffer error, reference address error, and the like.

In step S1022, the computer system outputs the analysis result of the memory error.

11A is a diagram showing an example of a program code for analyzing a memory error due to a release defect of an unallocated pointer, and FIG. 11B is a diagram illustrating memory information stored in an information tag storage unit.

FIG. 11A is a test code 1110, which shows an example in which the pointer bufp, which was dynamically allocated and used by the allocation function malloc, must be freed before termination, but the global variable buf is incorrectly entered into the free function. In one embodiment, the computer system analyzes the test code 1110 through binary analysis, and through this, information on buf (address 0x00010070, size 0x64) can be stored in the information tag storage unit. Operations of extracting information about buf through analysis of the test code 1110 and storing the extracted information in the information tag storage unit may be performed by the binary analysis module 112 (see FIG. 1 ).

A computer system uses information tagging to detect defects in a memory area. The computer system can collect information from the agent whenever a memory-related function is executed in the tc_free_main function. In one embodiment, the defect detection module 116 (see FIG. 1) is a malloc of 'int* bufp = (int*)malloc(sizeof(int))' statement 1112 described in line 4 of the test code 1110. When the function is called, the agent's malloc function can be called first. In the case of the syntax 1112, since there is no problem with the assigned parameter value, the defect detection module 116 calls the original malloc function, and if the result is not a NULL value, it can be stored in the information tag storage unit.

Information stored in the information tag storage unit 1120 by the binary analysis module 112 and the defect detection module 116 is shown in FIG. 11B.

The computer system may call the free function of the agent when the free statement 1114 of the sixth line of the test code 1110 is called. In this case, the memory address to be released is transferred to 0x10070, which is the address of buf, and the agent can search the information tag storage unit to check whether the corresponding value exists. Since buf is a value that exists in the information tag storage unit, the defect detection module (116, see FIG. 1) checks the allocation flag of the information tag storage unit first, and since the allocation flag value of 0x10070 is 0x1, which means static allocation, 'not allocated' It can be determined as a 'pointer free' fault. The fault detection module 116 may store a log related to unallocated pointer release as a trace log and terminate the code.

The computer system analyzes the trace log in the fault detection module 118 (see FIG. 1) to analyze the location of the source code where the 'unallocated pointer release' fault occurred and the fault log. In addition, the computer system may determine a memory leak if the information tag for bufp remains unreleased in the information tag storage. The fault log analysis and memory leak determination operations may be performed in the fault analysis module 114 (see FIG. 1).

The defect analysis module 114 may output the cause of the analyzed defect or memory error in text form.

The computer system and the memory error detection method performed by the computer system described in this specification may be implemented as a hardware component, a software component, and/or a combination of hardware components and software components.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. The device can be commanded.

Software may be implemented as a computer program including instructions stored in computer-readable storage media. Computer-readable recording media include, for example, magnetic storage media (e.g., read-only memory (ROM), random-access memory (RAM), floppy disk, hard disk, etc.) and optical reading media (e.g., CD-ROM) (CD-ROM) and DVD (Digital Versatile Disc). A computer-readable recording medium may be distributed among computer systems connected through a network, and computer-readable codes may be stored and executed in a distributed manner. The medium may be readable by a computer, stored in a memory, and executed by a processor.

A computer-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-temporary' only means that the storage medium does not contain a signal and is tangible, but does not distinguish whether data is stored semi-permanently or temporarily in the storage medium.

In addition, a computer system and a method for detecting a memory error in a computer system according to embodiments disclosed herein may be included in a computer program product and provided. Computer program products may be traded between sellers and buyers as commodities.

A computer program product may include a software program and a computer-readable storage medium in which the software program is stored. For example, a computer program product is a product in the form of a software program (eg, a downloadable application) that is distributed electronically through a manufacturer of an electronic device or an electronic market (eg, Google Play Store, App Store). ) may be included. For electronic distribution, at least a portion of the software program may be stored on a storage medium or temporarily created. In this case, the storage medium may be a storage medium of a manufacturer's server, an electronic market server, or a relay server temporarily storing a software program.

A computer program product may include a storage medium of a server or a storage medium of a terminal in a system including a server and a terminal (eg, an ultrasound diagnosis apparatus). Alternatively, if there is a third device (eg, a smart phone) that is communicatively connected to the server or terminal, the computer program product may include a storage medium of the third device. Alternatively, the computer program product may include a software program itself transmitted from the server to the terminal or the third device or from the third device to the terminal.

In this case, one of the server, the terminal and the third device may execute the computer program product to perform the method according to the disclosed embodiments. Alternatively, two or more of the server, the terminal, and the third device may execute the computer program product to implement the method according to the disclosed embodiments in a distributed manner.

For example, a server (eg, a cloud server or an artificial intelligence server) may execute a computer program product stored in the server and control a terminal connected to the server to perform a method according to the disclosed embodiments.

As another example, the third device may execute a computer program product to control a terminal communicatively connected to the third device to perform the method according to the disclosed embodiment.

When the third device executes the computer program product, the third device may download the computer program product from the server and execute the downloaded computer program product. Alternatively, the third device may perform the method according to the disclosed embodiments by executing a computer program product provided in a preloaded state.

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the methods described, and/or components such as the described computer systems or modules may be combined or combined in a manner different from the methods described, or other components or equivalents. Appropriate results can be achieved even if substituted or substituted by

Claims (20)

A method for detecting a memory error occurring in a computer system,
extracting global variable and local variable information of the application prior to execution of the application;
storing the extracted global variable and local variable information in an information tag repository; and
detecting a memory error based on the global variable and the local variable information stored in the information tag storage unit and dynamic memory information collected while the application is running;
Including, method.
◈Claim 2 was abandoned when the registration fee was paid.◈ According to claim 1,
In the step of extracting global variable and local variable information, a binary analyzer for extracting static memory information of the application is set to be executed before the application is executed according to a user input, and the global variable of the application is set through the binary analyzer. and extracting local variables.
◈Claim 3 was abandoned when the registration fee was paid.◈ According to claim 1,
The step of extracting the global variable and local variable information,
And analyzing at least one of an address, a size, and a call function of each of the extracted global variable and the local variable.
◈Claim 4 was abandoned when the registration fee was paid.◈ According to claim 1,
The detecting of the memory error includes monitoring the dynamic memory information that is dynamically allocated, accessed, and released from a heap area of memory by the running application through a dynamic binary injection (DBI) technique. .
According to claim 1,
The detecting of the memory error may include detecting a memory defect in at least one of a global area, a stack area, and a heap area of the memory.
According to claim 1,
According to the signal that a crash occurs in the application and the application is terminated, a signal handler of the kernel is directed to memory information at the time of the crash and memory defect information up to before the occurrence of the crash. replacing with a signal handler that monitors; Further comprising a method.
According to claim 6,
calling the replaced signal handler; and
Collecting call stack information of an application related to the crash using the called signal handler;
Further comprising a method.
◈Claim 8 was abandoned when the registration fee was paid.◈ According to claim 7,
The detecting of the memory error may include analyzing a cause of the memory error based on memory defect information in a global area, a stack area, and a heap area of memory and the collected call stack information.
◈Claim 9 was abandoned when the registration fee was paid.◈ According to claim 8,
outputting an analysis result of the memory error;
Further comprising a method.
A computer system for detecting memory errors,
Memory; and
a processor that detects a memory error generated when an application executed by the computer system refers to the memory;
including,
the processor,
a binary analysis module for extracting global variable and local variable information of the application prior to execution of the application;
a defect detection module configured to detect a defect of the memory based on the extracted global variable and local variable information; and
a defect analysis module that detects the memory error based on the detected memory defect and analyzes the detected error; Including, a computer system.
◈Claim 11 was abandoned when the registration fee was paid.◈ According to claim 10,
The binary analysis module sets a binary analyzer for extracting global variables and local variables of the application to be executed before the application is executed according to a user input, and extracts the global variables and local variables of the application through the binary analyzer , computer system.
◈Claim 12 was abandoned when the registration fee was paid.◈ According to claim 10,
a storage unit for storing the extracted static memory information;
Including more,
Wherein the defect detection module detects a defect in the memory based on the global variable and the local variable information stored in the storage unit.
◈Claim 13 was abandoned when the registration fee was paid.◈ According to claim 10,
Wherein the defect detection module analyzes at least one of an address, a size, and a call function of each of the extracted global variable and the local variable, and obtains information about the memory defect based on an analysis result.
◈Claim 14 was abandoned when the registration fee was paid.◈ According to claim 10,
Wherein the defect detection module monitors dynamic memory information that is dynamically allocated, accessed, and released from a heap area of the memory while the application is running using a Dynamic Binary Injection (DBI) technique.
According to claim 14,
The computer system of claim 1 , wherein the defect detection module detects a memory defect in at least one of a global area, a stack area, and the heap area of the memory.
According to claim 10,
The processor may include: a crash monitoring module that analyzes a crash that occurs while the application is running and collects data related to the crash; Further comprising a computer system.
According to claim 16,
The crash monitoring module sends a signal handler of a kernel according to a signal that a crash occurs in the application and the application is terminated, memory information at the time when the crash occurs and memory information until before the occurrence of the crash A computer system that replaces signal handlers that monitor fault information.
According to claim 17,
The computer system of claim 1 , wherein the crash monitoring module calls the replaced signal handler and collects call stack information of an application related to the crash using the called signal handler.
◈Claim 19 was abandoned when the registration fee was paid.◈ According to claim 18,
The defect analysis module analyzes the cause of the memory error based on memory defect information in the global area, stack area, and heap area of the memory detected by the defect detection module and the call stack information collected by the crash monitoring module. , computer system.
A computer-readable recording medium on which a program for executing the method of claim 1 is recorded on a computer.

Images