WO2019231194A1 - 메모리 오류를 검출하는 방법 및 시스템 - Google Patents

메모리 오류를 검출하는 방법 및 시스템 Download PDF

Info

Publication number
WO2019231194A1
WO2019231194A1 PCT/KR2019/006330 KR2019006330W WO2019231194A1 WO 2019231194 A1 WO2019231194 A1 WO 2019231194A1 KR 2019006330 W KR2019006330 W KR 2019006330W WO 2019231194 A1 WO2019231194 A1 WO 2019231194A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
information
application
crash
computer system
Prior art date
Application number
PCT/KR2019/006330
Other languages
English (en)
French (fr)
Inventor
장기훈
최병주
박지현
Original Assignee
삼성전자 주식회사
이화여자대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사, 이화여자대학교 산학협력단 filed Critical 삼성전자 주식회사
Publication of WO2019231194A1 publication Critical patent/WO2019231194A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance

Definitions

  • the present disclosure relates to a method and system for detecting a memory error caused by an application program running on a computer system. Specifically, the present disclosure relates to a method and system for detecting a crash error of a memory 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 the execution information of the application program according to a standard determined in a binary, mounting the binary on the memory, and referring to (read / write) the memory.
  • An application program running on a computer system may refer to any memory region by performing a series of memory instructions provided by the system, and may cause an error in the system due to an unintended memory reference.
  • the memory area used by an application program to run on a computer system is a static memory area that is fixed inside the application program even when the application program is executed, and a dynamic area that is created and destroyed as needed while the application program is executed. ) Divided into memory areas.
  • Conventional memory analysis techniques include pre-loading tools for detecting memory errors in the application program (Compile Time Instrumentation and Static Binary Instrumentation) and loading detection tools in advance just before the application program execution (Dynamic Binary). There is a method of mounting a detection tool (Dynamic Binary Injection) at any time during instrumentation and application program execution.
  • the present disclosure extracts global and local variables prior to execution of an application program, and utilizes the extracted global and local variables to detect memory errors, thereby not only detecting defects in dynamic memory, but also memory in global and stack regions. It also provides a method and system for detecting errors as well.
  • the present disclosure is to replace the signal handler of the kernel with a signal handler that monitors the memory defect information to collect the memory information at the time of the crash of the application program and the memory defect information until the crash occurs.
  • the method and system according to one embodiment of the present disclosure is directed to memory errors caused by global and stack regions of memory, as well as memory errors that occur when an application program is dynamically allocated, accessed, and released on a memory of a computer system. Since detection can also be performed, the accuracy of memory error detection can be improved.
  • the method and system according to an embodiment of the present disclosure outputs a result of monitoring the memory information at the time of occurrence of the crash number and the memory defect information until the crash occurs when a crash of the application program occurs, so that the user has a memory error. It can help to pinpoint the cause of the problem.
  • FIG. 1 is a block diagram illustrating components of a computer system according to an embodiment of the present disclosure.
  • FIG. 2 is a flowchart illustrating a method of detecting a memory error by a computer system according to an exemplary embodiment of the present disclosure.
  • FIG. 3 is a conceptual diagram showing the structure of an ELF file that is an executable file of an application program.
  • FIG. 4 is a diagram illustrating an example of program code used to extract information of global variables of an application program.
  • 5 is a diagram illustrating an example of program code used to extract information of local variables of an application program.
  • FIG. 6 is a diagram illustrating memory information stored in an information tag.
  • FIG. 7 is a block diagram illustrating components of a memory error detection system according to an embodiment of the present disclosure.
  • FIG. 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 exemplary embodiment of the present disclosure.
  • FIG. 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 exemplary embodiment of the present disclosure.
  • FIG. 10 is a flowchart illustrating a method of detecting, by a computer system, a memory error due to an application program, according to an exemplary embodiment.
  • FIG. 11A is a diagram illustrating an example of program code for analyzing a memory error due to a release defect of an unallocated pointer
  • FIG. 11B is a diagram illustrating memory information stored in an information tag storage unit.
  • an embodiment of the present disclosure comprises the steps of extracting global variable and local variable information of the application prior to the 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 the dynamic memory information collected while the application is executing. Provides a method for detecting errors.
  • the extracting of the global variable and local variable information may include setting a binary analyzer to extract static memory information of the application before the application is executed according to a user input, and executing the binary analyzer through the binary analyzer. You can extract global and local variables for your application.
  • the extracting of the 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 variable and the local variable.
  • detecting the memory error includes monitoring the dynamic memory information that is dynamically allocated, accessed, and released in the heap area of the memory by the running application through a dynamic binary injection (DBI) technique. can do.
  • DBI dynamic binary injection
  • the detecting of the memory error may detect a memory defect in at least one of the global area, the stack area, and the heap area of the memory.
  • a signal handler of a kernel is used to generate memory information and the crash at the time of the crash.
  • the method may further include replacing with a signal handler for monitoring memory defect information.
  • the method includes calling a replaced signal handler; And collecting call stack information of an application related to the crash by using the called signal handler.
  • the detecting of the memory error may analyze the cause of the memory error based on the memory defect information in the global area, the stack area, the heap area of the memory, and the collected call stack information.
  • the method may further include outputting an analysis result of the memory error.
  • an embodiment of the present disclosure is a memory; And a processor for detecting a memory error that occurs when an application executed by the computer system references the memory, wherein the processor is configured to execute a global variable and a local variable of the application before execution of the application.
  • local variable binary analysis module for extracting information;
  • a defect detection module detecting a defect of the memory based on the extracted global variable and the local variable information;
  • a defect analysis module that detects the memory error based on the detected memory defect and analyzes the detected error.
  • the binary analysis module sets a binary analyzer to extract global and local variables of the application before the application is executed according to a user input, and executes the global and local variables of the application through the binary analyzer. You can extract variables.
  • the computer system may further include a storage configured to store the extracted static memory information, and the defect detection module may detect a defect of the memory based on the global variable and the local variable information stored in the storage. Can be.
  • the defect detection module may analyze at least one of an address, a size, a call function of each of the extracted global variable and the local variable, and obtain information about the memory defect based on an analysis result. Can be.
  • the defect detection module may monitor dynamic memory information that is dynamically allocated, accessed, and released from the heap area of the memory while the application is running by using a dynamic binary injection (DBI) technique.
  • DBI dynamic binary injection
  • the defect detection module may detect a memory defect in at least one of the global area, the stack area, and the heap area of the memory.
  • the processor may further include a crash monitoring module that collects the crash related data by analyzing a crash generated while the application is executed.
  • a crash monitoring module that collects the crash related data by analyzing a crash generated while the application is executed.
  • the crash monitoring module may generate a signal handler of a kernel in response to a signal in which the crash occurs in the application, and generate memory information and the crash at the time when the crash occurs. You can replace it with a signal handler that monitors memory fault information up to now.
  • the crash monitoring module may call the replaced signal handler and collect call stack information of an application related to the crash by using the called signal handler.
  • the defect analysis module may determine the memory error based on the memory defect information in the global region, the stack region, the heap region of the memory detected by the defect detection module, and the call stack information collected by the crash monitoring module.
  • the cause of the analysis can be analyzed.
  • an embodiment of the present disclosure provides a computer program product comprising a computer-readable storage medium, the storage medium is a global variable of the application prior to the execution of the application (Global variable) ) 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 the dynamic memory information collected during execution of the application. can do.
  • ... unit means a unit for processing at least one function or operation, which is implemented in hardware or software or a combination of hardware and software. Can be.
  • the expression “configured to” is, for example, “suitable for”, “having the capacity to” depending on the context. It may be used interchangeably with “designed to”, “adapted to”, “made to”, or “capable of”.
  • the term “configured to” may not necessarily mean only “specifically designed to” in hardware. Instead, in some situations, the expression “system configured to” may mean that the system “can” together with other devices or components.
  • the phrase “processor configured (or configured to) perform A, B, and C” may be executed by executing a dedicated processor (eg, an embedded processor) or one or more software programs stored in memory to perform the operation. It may mean a general-purpose processor (for example, a CPU or an application processor) capable of performing corresponding operations.
  • a “computer system” is, for example, a desktop personal computer (PC), a laptop personal computer (PC), a netbook computer, a workstation, a server, a personal digital assistant (PDA). Etc., but is not limited thereto.
  • a computer system includes a smartphone, a tablet personal computer (PC), a mobile phone, a video phone, an e-book reader, a portable multimedia player ), An MP3 player, a mobile medical device, a camera, an electronic control device, or a wearable device.
  • an "application program” refers to a computer program running on an operating system (OS) of a computer system, and hereinafter referred to as "application” for simplicity and clarity of expression. .
  • FIG. 1 is a block diagram illustrating components of a computer system 100 according to an embodiment of the present disclosure.
  • the computer system 100 may include a processor 110, a memory 120, and a storage 130.
  • the computer system 100 may omit at least one of the components shown in FIG. 1 or may further include other components.
  • computer system 100 electrically connects processor 110, memory 120, and storage 130 to each other, and communicates between components (eg, control messages and / or data).
  • the bus may further include a bus.
  • the processor 110 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.
  • the processor 110 may be configured, for example, with at least one of a central processing unit (CPU), an application processor (AP), and a communication processor (CP), but is not limited thereto. no.
  • the processor 110 may be configured as any one of an application-specific integrated circuit (ASIC) chip, field-programmable gate arrays (FPGA), and a programmable-logic device.
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate arrays
  • the processor 110 is injected into each process of an analysis tool 110-1 that detects and analyzes an error in the memory 120 and an application that is executed in the computer system 100, and then the memory 120. It may include an agent (110-2) for monitoring the fault detection of the application and the crash (crash) of the application.
  • the analysis tool 110-1 may include a binary analysis module 112 and a defect analysis module 114.
  • Agent 110-2 may include fault detection module 116 and crash monitoring module 118.
  • the "module” may mean a unit including any one or a combination of hardware and software. "Module” may be replaced with terms such as, for example, unit, logic, logical block, component, or circuit. The module may be a minimum unit or part of performing one or more functions.
  • the binary analysis module 112, the defect analysis module 114, the defect detection module 116, and the crash monitoring module 118 are shown as separate things from each other, but are not limited to those shown.
  • binary analysis module 112, defect analysis module 114, defect detection module 116, and crash monitoring module 118 may be integrated into one module or a plurality of three or less modules.
  • the binary analysis module 112 may extract static memory information including global variables and local variables of an application executed by the computer system 100. In one embodiment, binary analysis module 112 may extract the global and local variables of the application before the application is executed on computer system 100. The binary analysis module 112 may first execute a binary analyzer that extracts global and local variables of the application before the application is executed through user input. In one embodiment, the binary analysis module 112 may set the binary analyzer to run as a default.
  • the binary analysis module 112 may extract a global variable and a local variable by analyzing a code of an ELF file of the application.
  • the binary analysis module 112 may store the extracted global variable and the local variable in the storage 130.
  • the binary analysis module 112 may extract the global and local variables by analyzing the code of the PE file of Windows. A detailed method of extracting the global and local variables of the application and storing them in the storage unit 130 by the binary analysis module 112 will be described in detail with reference to FIGS. 3 to 6.
  • the defect detection module 116 may detect a defect in the memory 120 based on the 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 extracted global and local variables of the extracted application, and based on the analysis result, the defect of the memory 120 is determined. Information can be obtained.
  • the defect detection module 116 may use dynamic binary injection (DBI) technology to monitor dynamic memory information that is dynamically allocated, accessed, and released in the heap area of the memory 120 while the application is running.
  • DBI dynamic binary injection
  • the defect detection module 116 detects memory defects in the global region and the stack region of the memory 120 based on the global variables and the local variables stored in the storage 130, and applies DBI technology. Memory defects may be detected by monitoring a function call in the heap region of the memory 120. Local variables may be stored in the stack region.
  • the defect detection module 116 may detect a defect in the memory using the memory address information stored in the storage 130. For example, the defect detection module 116 may determine that the value of the parameter of the memory allocation function that corresponds to the allocation size is '0' (zero-size memory allocation), or the execution result of the memory allocation function is NULL ( Memory allocation failure), and dynamic memory allocation that has not been released since the application terminated (memory leak) may be determined to be defective in memory allocation.
  • the address parameter value of the memory access function is NULL (null pointer access)
  • release flag value of the information tag for the pointer to be accessed is set (released pointer access) If the information tag for the pointer to be accessed does not exist and does not fit into the stack address space (unallocated pointer access), or if it is outside of the allocation size of the information tag for the pointer to be accessed (out of allocation). Access), and at least one of the cases where the string corresponding to the source of the string function is not ' ⁇ 0' processed (conflicts with the memory space of another variable). can do.
  • the defect detection module 116 does not have an information tag in the storage unit 130, or when the value of the allocation flag corresponds to a static allocation ( Unassigned pointer release), when the allocation function type flag value of the information tag is inconsistent with the type of the release function (assignment / release mismatch), and when the release flag on the information tag in the storage 130 is set (release Memory disaster), it may be determined that there is a defect related to memory release.
  • the crash monitoring module 118 may collect crash-related data by analyzing a crash that occurs when an application is incorrectly allocated, accessed, or released to the memory 120 while the application is running.
  • the crash monitoring module 118 may hook a signal to monitor the crash if the application crashes.
  • the crash monitoring module 118 may crash a signal handler of the kernel and memory information at the time of the crash according to a signal in which the crash occurs in the application and the application is terminated. You can replace it with a signal handler that monitors memory fault information until before 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 by using the called signal handler.
  • the crash monitoring module 118 may store the collected call stack information in the storage 130.
  • the defect analysis module 114 may output log information of the memory 120 by analyzing log information obtained from the agent 110-2.
  • the fault analysis module 114 collects the memory defect information in the global region, the stack region, the heap region of the memory 120 detected by the defect detection module 116, and the call 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 at which location a memory error occurs or cause of a memory error including a memory setting, a buffer error, a 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 be configured of, for example, a dynamic RAM (DRAM), a static RAM (SRAM), or a synchronous dynamic RAM (SDRAM), but is not limited thereto.
  • DRAM dynamic RAM
  • SRAM static RAM
  • SDRAM synchronous dynamic RAM
  • memory 120 may include a nonvolatile memory that stores software and / or programs.
  • the program may include, but is not limited to, a kernel, a library, and an application, for example.
  • the memory 120 may store middleware and an application programming interface (API).
  • API application programming interface
  • the storage unit 130 may store memory error information detected by the processor 110.
  • the storage unit 130 may be configured as one of a flash memory (eg, NAND flash or NOR flash), a hard drive, and a solid state drive (SSD).
  • a flash memory eg, NAND flash or NOR flash
  • NOR flash NOR flash
  • hard drive e.g., NOR flash
  • SSD solid state drive
  • the storage unit 130 is not limited to the examples listed.
  • the storage unit 130 may include an information tag repository that stores static memory information including global variables and local variables of the application extracted by the binary analysis module 112.
  • the storage unit 130 may store defect information in a heap area of the memory 120 analyzed by the defect detection module 116 in a log form.
  • 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 may store data analyzing the crash generated by the kernel itself as a kernel crash log. . This will be described in detail in the description of FIG. 10.
  • FIG. 2 is a flowchart illustrating a method of detecting a memory error by the computer system 100 according to an exemplary embodiment of the present disclosure.
  • step S210 the computer system 100 extracts the global and local variables of the application prior to the execution of the application.
  • the computer system 100 is configured to run a binary analyzer that first extracts global and local variables of the application before the application is executed according to user input, and then executes the application through the executed binary analyzer. You can extract global and local variables.
  • computer system 100 may analyze the code of the ELF file of the application to extract the global and local variables of the application.
  • the computer system 100 may analyze at least one of an address, a size, and a call function of each of the extracted global and local variables.
  • the computer system 100 stores the global variables and the local variables of the extracted application in the information tag repository.
  • Information tagging includes information about global and local variables (address, size) and information on heap areas that are dynamically allocated, accessed and freed (address, size, allocation function call stack, release function call stack, allocation function). Type) in the memory space. This will be described in detail in the description of FIG. 6.
  • step S230 the computer system 100 detects a memory error based on the stored global variable and local variable information and the dynamic memory information collected during execution of the application.
  • 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.
  • the computer system 100 may also use dynamic binary injection (DBI) technology to monitor dynamic memory information that is dynamically allocated, accessed, and released in the heap area of memory while the application is running. That is, the computer system 100 detects memory defects in the global area and the stack area of the memory based on the global variables and the local variables stored in the information tag storage unit, and uses the DBI technique to detect the memory defects in the heap area of the memory. Function calls can be monitored to detect memory faults.
  • DBI dynamic binary injection
  • the computer system 100 may hook a signal to monitor the crash if the crash occurs due to a memory corruption or the like while the application is running.
  • the computer system 100 may monitor memory information at the time of the crash of the application and memory defect information up to the occurrence of the crash, and collect call stack information related to the crash.
  • the computer system 100 may include defect information in a static memory area due to global and local variables of an application stored in the information tag storage, defect information in a dynamic memory area dynamically allocated, accessed, and released during application execution. Based on the stack information, the error of the memory can be detected and the cause of the error can be analyzed. In one embodiment, the computer system 100 may output the analysis results in text form.
  • the computer system and memory error detection method according to the embodiments shown in FIGS. 1 and 2 not only detects errors due to dynamic memory information that are dynamically allocated, accessed, or released due to execution of the application, but also before the application is executed. By extracting static memory information such as global and local variables of the application in advance and detecting the error of the memory by using the extracted static memory information, the accuracy of the memory error detection can be improved.
  • the computer system and the memory error detection method according to an embodiment of the present disclosure in the event of a crash of the application analyzes the result of monitoring the memory information at the time of occurrence of the crash number and memory defect information until the crash occurs, Outputting the analyzed results allows the user to pinpoint the cause of the memory error.
  • the computer system and the memory error detection method according to an embodiment of the present disclosure is efficient without the need for additional hardware equipment, the defect detection and error analysis of the memory by a software method, no additional cost and space is efficient .
  • the conventional Dynamic Binary Injection (DBI) technique is used, the execution binary does not need to be changed.
  • FIG. 3 is a conceptual diagram illustrating a structure of an ELF file 300 which is an executable file of an application
  • FIG. 4 is a diagram illustrating an example of program code 400 used to extract information of global variables of an application.
  • the ELF file 300 which is an executable file used in Linux or UNIX, includes a text area 310, an area for loading an execution command of an application, and variables necessary for executing the application.
  • the data area 320 may be stored, and the BSS area 330 which is an uninitialized data area may be included.
  • the initialized variable is stored in the data area 320 and may reside in the memory until the application is terminated.
  • Global variables are stored in the data area 320 and the BSS area 330.
  • the computer system may extract an address and a size of the global variable information stored in the data area 320 and the BSS area 330 of the ELF file 300.
  • global variable information may be extracted through a PE file, which is an executable file format of Windows.
  • the binary analysis module 112 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 a global variable of an application, and embodiments of the present disclosure are not limited to the illustrated program code.
  • the binary analysis module 112 creates a global variable called a buffer 410 like the program code 400, analyzes an ELF header, and analyzes the BSS region 330 of the ELF file 300 (see FIG. 3). Global variable address and size information can be extracted.
  • FIG. 5 is a diagram illustrating an example of a program code 500 used to extract information of a local variable of an application.
  • the binary analysis module 112 (refer to 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 be. 5 illustrates an example of a program code 500 for extracting a global variable of an application, and embodiments of the present disclosure are not limited to the illustrated program code.
  • an operation of adding or deleting a value to a stack pointer SP may be performed when the main function is executed.
  • the binary analysis module 112 analyzes a stack pointer add or delete operation of the program code 500 to extract local variable information including at least one of an address, a size, and a calling function of the local variable 520. Can be.
  • the address of the stack since the address of the stack is changed when the application is executed, the address of the local variable may be extracted as an offset value of the stack pointer.
  • FIG. 6 is a diagram illustrating memory information stored in an information tag 600.
  • the 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 the static memory region and the dynamic memory region.
  • the address 610 and the size 620 of the information tag 600 may store the address and the size of the global variable and the local variable of the application, as well as information about the address and the size of the heap memory area.
  • a general information tag stores only basic information (eg, address, size, etc.) about a specific memory area.
  • the information tag 600 according to an embodiment of the present disclosure further adds additional information such as allocation caller 660 and release caller 670 in the heap memory area to facilitate the cause analysis of the 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 the size 620 of each of the global variable and the local variable stored in the information tag 600.
  • the computer system 100 may detect an error in the dynamic memory area by using the information tag 600 to monitor call information of a function that is dynamically allocated, accessed, and released in the heap memory area.
  • the memory error detection system 700 is a system for detecting a memory error occurring on a computer system and analyzing a cause of the memory error.
  • the memory error detection system 700 may be implemented by the processor 110 (see FIG. 1). However, the present invention 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, sets of instructions, and a process for performing at least one or more functions.
  • the 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 can include a disassembler 712, a binary analyzer 714, a memory fault monitor 716, and at least one process P 1 -P n .
  • the inverse assembler 712 may provide information of binary files such as a library 704, a compiled object module, a shared object file, or a standalone executable file, and may represent an ELF file in an assembly language.
  • the disassembler 712 may disassemble the PE file in the Windows operating system to provide information of binary files.
  • the inverse assembler 712 may be implemented by a program such as Objdump, but is not limited thereto.
  • Binary analyzer 714 may be configured to extract global and local variables of the application before the application is executed in accordance with user input.
  • the binary analysis module 710 uses the inverse assembler 712 to disassemble an ELF file, which is an executable file of an application, and delivers the result to the binary analyzer 714, and the binary analyzer 714 is configured to execute the global variables and locals of the application. Information about the address and size of each variable can be extracted.
  • binary analyzer 714 may be set to default to be pre-operated before execution of the application.
  • the binary analysis module 710 may store the information about the address and size of the extracted global variable and the local variable in the information tag storage 734.
  • the binary analysis module 710 performs the same function as the binary analysis module 112 shown in FIG. 1, and thus descriptions thereof will be omitted.
  • the memory defect monitor 716 may analyze a call relation of a function when an application is executed, and analyze a trace log and a crash log to analyze a cause of a memory error. Trace logs and crash logs will be described in detail in the description of FIG. 10.
  • memory fault monitor 716 may be operated by fault analysis module 720.
  • the memory defect monitor 716 may analyze the defect information in the global area and the stack area of the memory based on the global variable and local variable information stored in the information tag storage 734.
  • the memory defect monitor 716 may analyze the dynamic memory defect information through the collected call stack information based on the function call information allocated, accessed, and released to the heap area of the memory when the application is executed. have.
  • the memory defect monitor 716 may analyze where the memory error occurred or cause of the memory error including memory setting, buffer error, reference address error, and the like.
  • Process may mean a unit of an application running on a computer system. For example, it may mean one execution window of a document creating application program.
  • the application 702 may include at least one process P 1 through P n .
  • the library 704 may provide a function commonly required by at least one process P 1 to P n .
  • the library 704 may perform, for example, a function related to input / output management, memory management, or a function call of at least one process P 1 to P n .
  • the library 704 may include a monitoring library (MMonitor.so) 732 and a user unit 742.
  • the monitoring library 732 may be called as the process (any of P 1 through P n ) is executed, and may track function call information allocated, accessed, and released to the heap area of memory by the process.
  • the monitoring library 732 may be called by the defect detection module 730.
  • the defect detection module 730 may store, in the information tag storage unit 734, function call information allocated, accessed, and released to the heap area of the memory.
  • the defect detection module 730 performs the same function as the defect detection module 116 shown in FIG. 1 except for including the information tag storage unit 734, and thus, a redundant description thereof will be omitted. Shall be.
  • the user unit 742 may perform a function of controlling the device driver 706. According to an embodiment, the user unit 742 may call stacks under the control of the kernel unit 744 when a crash occurs in any one of at least one process P 1 to P n . Information can be collected. This will be described in detail with reference to FIG. 10.
  • the device driver 706 may include a kernel unit 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 system resource status. When a crash occurs in the kernel, the kernel unit 744 may collect kernel crash information and store the collected kernel crash information in a log form.
  • user portion 742 and kernel portion 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 redundant description thereof will be omitted.
  • Operating system 708 can be any one of Linux, UNIX, and Windows, but is not limited to the examples listed.
  • FIG. 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 exemplary embodiment of the present disclosure.
  • step S810 the computer system extracts global and local variables of the application.
  • the computer system is configured to run a binary analyzer that first extracts the global and local variables of the application before the application is run, and then extracts the global and local variables of the application through the executed binary analyzer. can do.
  • the computer system may analyze the code in the ELF file of the application to extract at least one of an address, a size, and a call function of each of the global and local variables of the application.
  • the computer system may store the extracted global and local variables in an information tag repository.
  • step S820 the computer system executes the application.
  • the application may be executed as the execution instruction of the user is input.
  • the computer system can recognize it as a process.
  • a process may refer to a unit of an application running on a computer system. For example, it may mean one execution window of a document creating application program.
  • step S830 the computer system monitors dynamic memory information that is dynamically allocated, accessed, and released in the heap area of memory.
  • the computer system calls MMonitoring.so in 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. Trace function call information.
  • the computer system may monitor dynamic memory information that is dynamically allocated, accessed, and released in the heap area of the memory during a process by using a dynamic binary injection (DBI) technique.
  • DBI dynamic binary injection
  • 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.
  • 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 the global and local variables of the application stored in the information tag storage.
  • the computer system may use a DBI technique to monitor for function calls in the heap area of memory to detect defects in the dynamic memory area.
  • FIG. 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 exemplary embodiment of the present disclosure.
  • step S910 the computer system replaces a signal handler of the kernel with a signal handler that monitors the occurrence of a crash by an application.
  • the computer system may request the kernel to replace the signal handler in advance before the application is executed in user mode.
  • the kernel may replace the preset signal handler with a signal handler that monitors the memory information at the time the crash occurs in the application and the memory defect information until the crash occurs.
  • step S920 the computer system calls the replaced signal handler. If a crash occurs due to memory corruption or the like during a process operation by an application running on a computer system, the signal handler replaced in step S910 in the kernel is called instead. That is, the kernel can call the replaced signal handler in response to a signal that the process has crashed.
  • the computer system collects call stack information.
  • the computer system may use a signal handler called in the kernel to collect call stack information to analyze information related to the crash that occurred in the process.
  • the call stack information may mean history information about a function call that allocates, accesses, or releases a variable in memory by a process.
  • step S940 the computer system analyzes the cause of the memory error based on the collected call stack information.
  • the computer system may analyze the cause of the memory error, including the error location of the dynamic memory area, memory settings, buffer error, reference address error, and the like, based on the collected call stack information.
  • the computer system may store the memory error cause information obtained through the call stack information as an application crash log.
  • an error detection mode of a computer system may include a system resource used to execute an application and to execute a user mode 1001 for detecting a memory error by an executed application and an operation or function implemented in the application. It may include a kernel mode 1002 that controls / manages.
  • the kernel mode may be a mode that operates in an operating system such as Linux or UNIX. However, the operating system in which kernel mode is operated is not limited to nix or unix.
  • step S1011 the computer system extracts global and local variables of the application.
  • the computer system may first run a binary analyzer that extracts the global and local variables of the application before the application is executed, and extract the global and local variables of the application through the executed binary analyzer.
  • the computer system may analyze code in the ELF file of the application to analyze at least one of an address, a size, and a call function of each of the global and local variables of the application.
  • the computer system stores the global variables and the local variables of the extracted application in the information tag repository 1050.
  • the information tag storage unit 1050 may store information about the address and size of each of the global variable and the local variable. 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 thus descriptions thereof will be omitted.
  • step S1013 the computer system injects a crash monitoring module into the kernel.
  • step S1014 the computer system requests the kernel to replace the signal handler, and in step S1041 the kernel replaces the signal handler.
  • the user mode 1001 may request the kernel to replace the kernel's signal handler with a signal handler that monitors the occurrence of a crash by the application.
  • the request for replacing the signal handler in the user mode 1001 may be performed before step S1015 of executing the application. That is, the computer system may request the kernel to replace the signal handler in advance before the application is executed in user mode 1001.
  • the kernel can replace the predetermined signal handler with a signal handler that monitors memory information at the time of crash occurrence in the application and memory defect information until the occurrence of the crash (step S1041).
  • step S1015 the computer system executes the application.
  • the application may be executed as the execution instruction of the user is input in the user mode 1001.
  • the computer system can recognize it as a process.
  • a process may refer to a unit of an application running on a computer system.
  • the computer system collects the call information of the allocation, freeing, and accessing function of the dynamic memory area through a dynamic binary injection (DBI) method.
  • the computer system calls MMonitoring.so in the library as soon as the application is executed in user mode 1001, and uses a called MMonitoring.so to call a function that is allocated, accessed, and freed in the heap area of memory. Information can be traced.
  • the computer system may store the function call information in the information tag storage 1050.
  • the information tag storage unit 1050 not only includes static memory information including global variables and local variables, but also information on heap areas that are dynamically allocated, accessed and released (eg, address, size, allocation function call stack). , Release function call stack, and allocation function type).
  • the computer system detects memory defects in the global area, the stack area, and the heap area.
  • the computer system may use the DBI method to monitor dynamic memory information that is dynamically allocated, accessed, and released in the heap area of memory by execution of an application, and may detect memory defects in the heap area.
  • the computer system detects 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 the global and local variables of the application stored in the information tag storage 1050. Can be.
  • the computer system may detect a defect in the memory using memory address information or size information stored in the information tag storage unit 1050 when the memory allocation, access, and release related functions are executed. For example, if a computer system has a parameter value of '0' (zero-size memory allocation) among the parameters of the memory allocation function (zero-size memory allocation), and the execution result of the memory allocation function is NULL (memory allocation failure) At least one of the cases in which there is a dynamic memory allocation (memory leak) that has not been released since the application is terminated may be determined to have a defect related to the memory allocation.
  • '0' zero-size memory allocation
  • NULL memory allocation failure
  • the pointer to be accessed is If the information tag for does not exist and does not fall within the stack address space (unallocated pointer access), is outside the range of the allocation size of the information tag for the pointer to be accessed (access outside the allocation range), and It may be determined that there is a defect related to memory access in at least one of the cases in which the string corresponding to the source of the string function is not processed with ' ⁇ 0' (conflict with the memory space of another variable).
  • the computer system may determine that an information tag does not exist in the information tag storage unit 1050 when the parameter value of the memory release function is NULL (null pointer is released), or that the value of the allocation flag corresponds to a static allocation (not allocated). Unfree pointers), at least one of the information tag's allocation function type flag value is inconsistent with the free function's type (assignment / release mismatch), and the information tag has the release flag set (released memory reclaim). In this case, it may be determined that there is a defect related to memory release.
  • 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 heap area as well as the global area and the stack area of the memory.
  • 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 thus descriptions thereof will be omitted.
  • step S1042 the computer system calls the replaced signal handler in kernel mode 1002.
  • the kernel mode 1002 may call the signal handler replaced in step S1041 according to a signal indicating that the application has crashed due to memory corruption in an application executed in the user mode 1001. have.
  • the computer system collects call stack information.
  • the computer system may collect call stack information that may analyze information related to a crash that occurred in an application using a signal handler called in kernel mode 1002.
  • the call stack information may mean history information about a function call that allocates, accesses, or releases a variable in memory by an application.
  • 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 generated by an application executed in the user mode 1001.
  • the kernel collects analysis data related to the crash that occurred in the kernel itself.
  • the crash that occurs in the kernel itself can occur when an application cannot make a request in the kernel when an application requests memory resources from the kernel. For example, a crash may occur in the kernel when an application attempts to access system memory, or allocate a variable beyond its size.
  • state information of a kernel related to a crash may be collected, for example, current state information of a whole memory including a global region, a stack region, and a heap region, or information related to a resource situation of a system.
  • step S1046 the computer system stores the crash analysis data in the kernel crash log 1072 and ends.
  • the kernel crash log 1072 may store crash information related to the kernel, that is, status information of the entire memory at the time of collection or information related to resource status of the system. Terminating in step S1046 is the kernel itself, which is different from steps S1033 and S1044 in which the application is terminated.
  • Steps S1041 to S1046 may be performed by the crash monitoring module 1040.
  • the crash monitoring module 1040 performs the same function as the crash monitoring module 118 shown in FIG. 1, and thus redundant descriptions thereof will be omitted.
  • 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.
  • the computer system is statically configured with memory fault information in the global, stack, and heap regions of memory stored in trace log 1060 and call stack information stored in application crash log 1071. And error sources of dynamic memory.
  • the computer system may analyze the causes of memory errors, such as where the error occurred in the memory, memory settings, buffer errors, reference address errors, and the like.
  • step S1022 the computer system outputs an analysis result of the memory error.
  • FIG. 11A is a diagram illustrating an example of program code for analyzing a memory error due to a release defect of an unallocated pointer
  • FIG. 11B is a diagram illustrating memory information stored in an information tag storage unit.
  • FIG. 11A illustrates a test code 1110 in which the pointer buf, which has been dynamically allocated with malloc, which is an allocation function, needs to be released before termination.
  • FIG. 11A illustrates an example in which the global variable buf is incorrectly entered into the release function.
  • the computer system analyzes the test code 1110 through binary analysis, thereby storing information about buf (address 0x00010070, size 0x64) in the information tag storage. 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).
  • the computer system uses information tagging to detect defects in the memory area.
  • the computer system may collect information from the agent each time a memory related function is executed in the tc_free_main function.
  • Information stored in the information tag storage unit 1120 by the binary analysis module 112 and the defect detection module 116 is as shown in FIG. 11B.
  • the computer system may call the agent's free function when the free statement 1114 of line 6 of the test code 1110 is called.
  • the memory address to be released comes to 0x10070, which is the address of buf, and the agent can check the existence of the corresponding value by searching the information tag storage. Since buf is a value present in the information tag storage unit, the defect detection module 116 first checks an allocation flag of the information tag storage unit, and an allocation flag value of 0x10070 is 0x1, which means static allocation. Not free pointer 'fault.
  • the defect detection module 116 may store a log related to unallocated pointer release as a trace log and terminate the code.
  • the computer system may analyze the trace log in the defect detection module 118 (see FIG. 1) to analyze the location of the source code where the 'unassigned pointer release' defect occurs and the defect log.
  • the computer system may also determine a memory leak if the information tag for buf remains unreleased in the information tag storage.
  • the defect log analysis and memory leak determination operations may be performed by the defect analysis module 114 (see FIG. 1).
  • the defect analysis module 114 may output the analyzed defect or the cause of the memory error in text form.
  • the memory system and the method for detecting memory errors performed by the computer system described herein may be implemented by hardware components, software components, and / or combinations of hardware components and software components.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device.
  • the software may be implemented as a computer program including instructions stored in a computer-readable storage media.
  • Computer-readable recording media include, for example, magnetic storage media (eg, read-only memory (ROM), random-access memory (RAM), floppy disks, hard disks, etc.) and optical read media (eg, CD-ROMs). (CD-ROM) and DVD (Digital Versatile Disc).
  • the computer readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
  • the medium is readable by the computer, stored in the memory, and can be executed by the processor.
  • the computer readable storage medium may be provided in the form of a non-transitory storage medium.
  • 'non-temporary' means that the storage medium does not include a signal and is tangible, but does not distinguish that the data is stored semi-permanently or temporarily on the storage medium.
  • a computer system and a method for detecting a memory error in the computer system according to the embodiments disclosed herein may be provided included in a computer program product.
  • the computer program product may be traded between the seller and the buyer as a product.
  • the computer program product may include a software program, a computer-readable storage medium on which the software program is stored.
  • a computer program product may be a product (eg, a downloadable application) in the form of a software program distributed electronically through a manufacturer of an electronic device or an electronic market (eg, Google Play Store, App Store). ) May be included.
  • the storage medium may be a server of a manufacturer, a server of an electronic market, or a storage medium of a relay server that temporarily stores a software program.
  • the computer program product may include a storage medium of a server or a storage medium of a terminal in a system consisting of a server and a terminal (for example, an ultrasound diagnostic apparatus).
  • a third device eg, a smartphone
  • the computer program product may include a storage medium of the third device.
  • the computer program product may include a software program itself transmitted from the server to the terminal or the third device, or transmitted from the third device to the terminal.
  • 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.
  • two or more of the server, the terminal and the third device may execute a computer program product to distribute and implement the method according to the disclosed embodiments.
  • a server eg, a cloud server or an artificial intelligence server, etc.
  • a server may execute a computer program product stored in the server to control a terminal connected to the server to perform the method according to the disclosed embodiments.
  • a third device may execute a computer program product to control a terminal in communication with the third device to perform the method according to the disclosed embodiment.
  • the third device may download the computer program product from the server and execute the downloaded computer program product.
  • the third apparatus may execute the provided computer program product in a preloaded state to perform the method according to the disclosed embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

컴퓨터 시스템에서 실행되는 애플리케이션 프로그램에 의해 발생되는 메모리 오류를 검출하는 방법 및 시스템을 제공한다. 본 개시의 일 실시예는 애플리케이션의 실행 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하고, 추출된 글로벌 변수 및 로컬 변수를 인포메이션 태그 저장부에 저장하고, 저장된 글로벌 변수 및 로컬 변수의 정보에 기초하여 정적 메모리 오류를 검출하고, 애플리케이션의 실행 중에 수집된 동적 메모리 오류를 검출하는 방법 및 컴퓨터 시스템을 제공한다.

Description

메모리 오류를 검출하는 방법 및 시스템
본 개시는 컴퓨터 시스템에서 실행되는 애플리케이션 프로그램에 의해 발생되는 메모리 오류를 검출하는 방법 및 시스템에 관한 것이다. 구체적으로, 본 개시는 애플리케이션 프로그램의 잘못된 메모리 참조로 인하여 발생되는 메모리의 크래쉬(crash) 오류를 바이너리(binary) 기반으로 검출하고, 메모리 오류의 원인을 분석하는 방법 및 시스템에 관한 것이다.
컴퓨터 시스템은 애플리케이션 프로그램의 실행 정보를 바이너리(binary)에 정해진 규격에 의해 기록하고, 해당 바이너리를 메모리 상에 탑재한 후 메모리를 참조(읽기/쓰기)함으로써 애플리케이션 프로그램을 실행한다. 컴퓨터 시스템 상에서 실행되는 애플리케이션 프로그램은 시스템에서 제공하는 일련의 메모리 명령(instruction)을 수행하여 임의의 메모리 영역을 참조할 수 있고, 의도하지 않는 메모리 참조로 인하여 시스템의 오류(error)를 유발할 수 있다.
애플리케이션 프로그램이 컴퓨터 시스템 상에서 실행되기 위해 사용되는 메모리 영역은, 애플리케이션 프로그램이 실행되더라도 애플리케이션 프로그램 내부에 고정되어 있는 정적(static) 메모리 영역 및 애플리케이션 프로그램이 실행되는 동안 필요에 따라 생성/소멸 되는 동적(dynamic) 메모리 영역으로 구분된다.
종래의 메모리 분석 기술은 애플리케이션 프로그램에 메모리 오류를 검출하기 위한 도구를 컴파일 시점에 사전에 탑재하는 방식(Compile Time Instrumentation 및 Static Binary Instrumentation)과 애플리케이션 프로그램 수행 직전에 미리 검출 도구를 탑재하는 방식(Dynamic Binary Instrumentation) 및 애플리케이션 프로그램 실행 중의 임의의 시점에 검출 도구를 탑재하는 방식(Dynamic Binary Injection)이 존재한다.
종래의 프로그램 실행 중에 도구를 탑재하여 메모리 오류를 검출하는 기술들은 애플리케이션 프로그램의 실행 시점 이후에 메모리 검출 도구가 탑재되기 때문에 메모리 검출 도구의 탑재 이후 시점에서 접근, 할당, 및 해제되는 동적 메모리 오류는 분석 가능하지만, 애플리케이션의 실행 이전에 할당이 완료된 글로벌 변수(Global variable) 및 스택 영역(Stack)에 할당되는 로컬 변수(Local variable)에 대해서는 정보를 획득할 수 없어 메모리의 글로벌 영역 및 스택 영역에서 발생되는 메모리 오류는 검출해낼 수 없는 문제점이 있다.
또한, 메모리 오류가 발생한다 하더라도 애플리케이션 프로그램이 의도하지 않은 방향으로 계속적으로 실행될 수 있으며, 이후 더 이상 애플리케이션 프로그램이 실행될 수 없는 상황이 되었을 때 시스템 크래쉬(crash)가 발생되어 종료되지만, 해당 종료 시점에서 메모리 오류의 원인에 관한 정보를 알 수 없어 프로그램 오류를 수정하는데 어려움이 있다.
본 개시는 애플리케이션 프로그램의 실행 전에 글로벌 변수 및 로컬 변수를 추출하고, 추출된 글로벌 변수 및 로컬 변수를 활용하여 메모리 오류를 검출함으로써, 동적 메모리의 결함을 검출할 뿐만 아니라 글로벌 영역 및 스택 영역에서의 메모리 오류도 함께 검출할 수 있는 방법 및 시스템을 제공한다.
또한, 본 개시는 커널(kernel)의 시그널 핸들러(signal handler)를 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체함으로써 애플리케이션 프로그램의 크래쉬가 발생한 시점의 메모리 정보 및 크래쉬 발생 이전까지의 메모리 결함 정보를 수집하여 메모리 오류의 원인 분석을 용이하게 하는 방법 및 시스템을 제공한다.
본 개시의 일 실시예에 따른 방법 및 시스템은, 애플리케이션 프로그램이 컴퓨터 시스템의 메모리 상에 동적으로 할당, 접근 및 해제 시에 발생되는 메모리 오류 뿐만 아니라, 메모리의 글로벌 영역 및 스택 영역으로 인한 메모리 오류에 대해서도 검출이 가능하므로, 메모리 오류 검출의 정확성을 향상시킬 수 있다.
또한, 본 개시의 일 실시예에 따른 방법 및 시스템은 애플리케이션 프로그램의 크래쉬가 발생하는 경우 크래수의 발생 시점의 메모리 정보 및 크래쉬 발생 이전까지의 메모리 결함 정보를 모니터링한 결과를 출력함으로써 사용자가 메모리 오류의 원인을 정확하게 파악할 수 있도록 할 수 있다.
본 개시는, 다음의 자세한 설명과 그에 수반되는 도면들의 결합으로 쉽게 이해될 수 있으며, 참조 번호(reference numerals)들은 구조적 구성요소(structural elements)를 의미한다.
도 1은 본 개시의 일 실시예에 따른 컴퓨터 시스템의 구성 요소를 도시한 블록도이다.
도 2는 본 개시의 일 실시예에 따른 컴퓨터 시스템이 메모리 오류를 검출하는 방법을 도시한 흐름도이다.
도 3은 애플리케이션 프로그램의 실행 파일인 ELF 파일의 구조를 도시한 개념도이다.
도 4는 애플리케이션 프로그램의 글로벌 변수의 정보를 추출하는데 사용하는 프로그램 코드의 일 례를 도시한 도면이다.
도 5는 애플리케이션 프로그램의 로컬 변수의 정보를 추출하는데 사용하는 프로그램 코드의 일 례를 도시한 도면이다.
도 6은 인포메이션 태그(information tag)에 저장되는 메모리 정보를 도식화한 도면이다.
도 7은 본 개시의 일 실시예에 따른 메모리 오류 검출 시스템의 구성 요소를 도시한 블록도이다.
도 8은 본 개시의 일 실시예에 따른 컴퓨터 시스템이 메모리의 글로벌 영역, 스택 영역 및 Heap 영역 중 적어도 하나의 영역에서의 메모리 결함을 검출하는 방법을 도시한 흐름도이다.
도 9는 본 개시의 일 실시예에 따른 컴퓨터 시스템이 시그널 핸들러를 교체하여 동적 메모리 영역의 오류의 원인을 검출하고, 이를 분석하는 방법을 도시한 흐름도이다.
도 10은 본 개시의 일 실시예에 따른 컴퓨터 시스템이 애플리케이션 프로그램으로 인한 메모리 오류를 검출하는 방법을 도시한 흐름도이다.
도 11a는 할당되지 않은 포인터의 해제 결함으로 인한 메모리 오류를 분석하기 위한 프로그램 코드의 일 례를 도시한 도면이고, 도 11b는 인포메이션 태그 저장부에 저장된 메모리 정보를 도식화한 도면이다.
상술한 기술적 과제를 해결하기 위하여, 본 개시의 일 실시예는 애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 단계; 추출된 상기 글로벌 변수 및 상기 로컬 변수 정보를 인포메이션 태그 저장부(information tag repository)에 저장하는 단계; 및 상기 인포메이션 태그 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보와 상기 애플리케이션이 실행 중에 수집된 동적 메모리(dynamic memory) 정보에 기초하여 메모리 오류를 검출하는 단계를 포함하는, 컴퓨터 시스템에서 발생되는 메모리 오류를 검출하는 방법을 제공한다.
예를 들어, 상기 글로벌 변수 및 로컬 변수 정보를 추출하는 단계는, 사용자 입력에 따라 상기 애플리케이션이 실행되기 전에 상기 애플리케이션의 정적 메모리 정보를 추출하는 바이너리 분석기를 실행하도록 설정하고, 상기 바이너리 분석기를 통해 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다.
예를 들어, 상기 글로벌 변수 및 로컬 변수 정보를 추출하는 단계는 추출된 상기 글로벌 변수 및 상기 로컬 변수 각각의 주소(address), 크기, 호출함수 중 적어도 하나를 분석하는 단계를 포함할 수 있다.
예를 들어, 상기 메모리 오류를 검출하는 단계는 DBI(Dynamic Binary Injection) 기법을 통해 상기 실행 중인 애플리케이션에 의해 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 상기 동적 메모리 정보를 모니터링하는 단계를 포함할 수 있다.
예를 들어, 상기 메모리 오류를 검출하는 단계는 메모리의 글로벌 영역, 스택 영역(Stack) 및 Heap 영역 중 적어도 하나의 영역에서의 메모리 결함을 검출할 수 있다.
예를 들어, 상기 방법은 애플리케이션에 크래쉬(crash)가 발생되어 상기 애플리케이션이 종료되는 신호에 따라, 커널(kernel)의 시그널 핸들러(signal handler)를 상기 크래쉬가 발생한 시점의 메모리 정보 및 상기 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체하는 단계를 더 포함할 수 있다.
예를 들어, 상기 방법은 교체된 시그널 핸들러를 호출하는 단계; 및 호출된 시그널 핸들러를 이용하여 상기 크래쉬와 관련된 애플리케이션의 콜 스택(Call Stack) 정보를 수집하는 단계를 더 포함할 수 있다.
예를 들어, 상기 메모리 오류를 검출하는 단계는 메모리의 글로벌 영역, 스택 영역, Heap 영역에서의 메모리 결함 정보 및 상기 수집된 콜 스택 정보에 기초하여 상기 메모리 오류의 원인을 분석할 수 있다.
예를 들어, 상기 방법은 메모리 오류의 분석 결과를 출력하는 단계를 더 포함할 수 있다.
상술한 기술적 과제를 해결하기 위하여, 본 개시의 일 실시예는 메모리; 및 상기 컴퓨터 시스템에 의해 수행되는 애플리케이션이 상기 메모리를 참조함에 따라 발생되는 메모리 오류를 검출하는 프로세서를 포함하고, 상기 프로세서는 상기 애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 바이너리 분석 모듈; 추출된 상기 글로벌 변수 및 상기 로컬 변수 정보에 기초하여 상기 메모리의 결함을 탐지하는 결함 탐지 모듈; 및 상기 탐지된 메모리 결함에 기초하여 상기 메모리 오류를 검출하고, 검출된 오류를 분석하는 결함 분석 모듈을 포함하는, 메모리 오류를 검출하는 컴퓨터 시스템을 제공한다.
예를 들어, 상기 바이너리 분석 모듈은 사용자 입력에 따라 상기 애플리케이션이 실행되기 전에 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기가 실행되도록 설정하고, 상기 바이너리 분석기를 통해 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다.
예를 들어, 상기 컴퓨터 시스템은 추출된 정적 메모리 정보를 저장하는 저장부를 더 포함하고, 상기 결함 탐지 모듈은 상기 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보에 기초하여 상기 메모리의 결함을 탐지할 수 있다.
예를 들어, 상기 결함 탐지 모듈은 추출된 상기 글로벌 변수 및 상기 로컬 변수 각각의 주소(address), 크기, 호출함수 중 적어도 하나를 분석하고, 분석 결과에 기초하여 상기 메모리 결함에 관한 정보를 획득할 수 있다.
예를 들어, 상기 결함 탐지 모듈은 DBI(Dynamic Binary Injection) 기법을 사용하여 상기 애플리케이션이 실행 중에 상기 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링할 수 있다.
예를 들어, 상기 결함 탐지 모듈은 상기 메모리의 글로벌 영역, 스택 영역(Stack) 및 상기 Heap 영역 중 적어도 하나의 영역에서의 메모리 결함을 검출할 수 있다.
예를 들어, 상기 프로세서는 상기 애플리케이션이 실행 중에 발생되는 크래쉬(crash)를 분석하여 상기 크래쉬 관련 데이터를 수집하는 크래쉬 모니터링 모듈을 더 포함할 수 있다.
예를 들어, 상기 크래쉬 모니터링 모듈은 상기 애플리케이션에 크래쉬가 발생되어 상기 애플리케이션이 종료되는 신호에 따라, 커널(kernel)의 시그널 핸들러(signal handler)를 상기 크래쉬가 발생한 시점의 메모리 정보 및 상기 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체할 수 있다.
예를 들어, 상기 크래쉬 모니터링 모듈은 상기 교체된 시그널 핸들러를 호출하고, 상기 호출된 시그널 핸들러를 이용하여 상기 크래쉬와 관련된 애플리케이션의 콜 스택(Call Stack) 정보를 수집할 수 있다.
예를 들어, 상기 결함 분석 모듈은 상기 결함 탐지 모듈에서 탐지한 상기 메모리의 글로벌 영역, 스택 영역, Heap 영역에서의 메모리 결함 정보 및 상기 크래쉬 모니터링 모듈에서 수집한 상기 콜 스택 정보에 기초하여 상기 메모리 오류의 원인을 분석할 수 있다.
상술한 기술적 과제를 해결하기 위하여, 본 개시의 일 실시예는 컴퓨터로 읽을 수 있는 저장 매체를 포함하는 컴퓨터 프로그램 제품을 제공하고, 상기 저장 매체는 애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 단계; 추출된 상기 글로벌 변수 및 상기 로컬 변수 정보를 인포메이션 태그 저장부(information tag repository)에 저장하는 단계; 및 상기 인포메이션 태그 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보와 상기 애플리케이션이 실행 중에 수집된 동적 메모리(dynamic memory) 정보에 기초하여 메모리 오류를 검출하는 단계를 수행하는 명령어들(instructions)을 포함할 수 있다.
본 명세서의 실시예들에서 사용되는 용어는 본 개시의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 실시예의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 용어들은 본 명세서에 기재된 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가질 수 있다.
명세서 전체에서 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 "...부", "...모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.
본 명세서에서 사용된 표현 "~하도록 구성된(또는 설정된)(configured to)"은 상황에 따라, 예를 들면, "~에 적합한(suitable for)", "~하는 능력을 가지는(having the capacity to)", "~하도록 설계된(designed to)", "~하도록 변경된(adapted to)", "~하도록 만들어진(made to)", 또는 "~를 할 수 있는(capable of)"과 바꾸어 사용될 수 있다. 용어 "~하도록 구성된(또는 설정된)"은 하드웨어적으로 "특별히 설계된(specifically designed to)" 것만을 반드시 의미하지 않을 수 있다. 대신, 어떤 상황에서는, "~하도록 구성된 시스템"이라는 표현은, 그 시스템이 다른 장치 또는 부품들과 함께 "~할 수 있는" 것을 의미할 수 있다. 예를 들면, 문구 "A, B, 및 C를 수행하도록 구성된(또는 설정된) 프로세서"는 해당 동작을 수행하기 위한 전용 프로세서(예: 임베디드 프로세서), 또는 메모리에 저장된 하나 이상의 소프트웨어 프로그램들을 실행함으로써, 해당 동작들을 수행할 수 있는 범용 프로세서(generic-purpose processor)(예: CPU 또는 application processor)를 의미할 수 있다.
본 개시에서, "컴퓨터 시스템"은 예를 들면, 데스크탑 PC(desktop personal computer), 랩탑 PC(laptop personal computer), 넷북 컴퓨터(netbook computer), 워크스테이션(workstation), 서버, PDA(personal digital assistant) 등을 의미하나, 이에 한정되는 것은 아니다. 본 개시의 일 실시예에서, 컴퓨터 시스템은 스마트폰(smartphone), 태블릿 PC(tablet personal computer), 이동 전화기(mobile phone), 영상 전화기, 전자책 리더기(e-book reader), PMP(portable multimedia player), MP3 플레이어, 모바일 의료기기, 카메라(camera), 자동자 전자 제어 장치, 또는 웨어러블 장치(wearable device) 중 적어도 하나를 포함할 수 있다.
본 개시에서, "애플리케이션 프로그램(application program)"은 컴퓨터 시스템의 운영 체제(Operating System, OS) 상에서 구동되는 컴퓨터 프로그램을 의미하고, 표현의 간소화 및 명확화를 위해 이하에서는 "애플리케이션"으로 지칭하기로 한다.
아래에서는 첨부한 도면을 참고하여 본 개시의 실시예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.
이하에서는 도면을 참조하여 본 개시의 실시예들을 상세하게 설명한다.
도 1은 본 개시의 일 실시예에 따른 컴퓨터 시스템(100)의 구성 요소를 도시한 블록도이다.
도 1을 참조하면, 컴퓨터 시스템(100)은 프로세서(110), 메모리(120), 및 저장부(130)을 포함할 수 있다. 컴퓨터 시스템(100)은, 도 1에 도시된 구성 요소 중 적어도 하나를 생략하거나, 또는 다른 구성 요소를 추가적으로 포함할 수 있다. 일 실시예에서, 컴퓨터 시스템(100)은 프로세서(110), 메모리(120), 및 저장부(130)를 서로 전기적으로 연결하고, 구성 요소들 간의 통신(예를 들어, 제어 메시지 및/또는 데이터)을 전달하는 버스(bus)를 더 포함할 수 있다.
프로세서(110)는 메모리(120)에 저장된 컴퓨터로 읽을 수 있는 명령어(instruction) 또는 데이터를 로드(load)하고, 로드된 명령어 또는 데이터에 따라 적어도 하나의 소프트웨어 프로그램을 실행하는 범용 프로세서(generic-purpose processor)일 수 있다. 프로세서(110)는 예를 들어, 중앙 처리 장치(Central Processing Unit, CPU), 어플리케이션　프로세서(Application Processor, AP), 및 커뮤니케이션　프로세서(Communication Processor, CP) 중 적어도 하나로 구성될 수 있으나, 이에 한정되는 것은 아니다. 일 실시예에서, 프로세서(110)는 ASIC(application-specific integrated circuit) 칩, FPGA(field-programmable gate arrays), 및 프로그램 가능 논리 장치(programmable-logic device) 중 어느 하나로 구성될 수도 있다.
프로세서(110)는 메모리(120)의 오류를 검출하고, 분석하는 분석 도구(110-1) 및 컴퓨터 시스템(100)에서 실행되는 애플리케이션의 각 프로세스(process)에 삽입(injection)되어 메모리(120)의 결함 탐지 및 애플리케이션의 크래쉬(crash)를 모니터링하는 에이전트(agent)(110-2)를 포함할 수 있다.
분석 도구(110-1)는 바이너리 분석 모듈(112) 및 결함 분석 모듈(114)을 포함할 수 있다. 에이전트(110-2)는 결함 탐지 모듈(116) 및 크래쉬 모니터링 모듈(118)을 포함할 수 있다. 여기서, "모듈"은 하드웨어 및 소프트웨어 중 어느 하나 또는 이들의 조합을 포함하는 단위(unit)를 의미할 수 있다. "모듈"은 예를 들면, 유닛(unit), 로직(logic), 논리 블록(logical block), 부품(component), 또는 회로(circuit) 등의 용어로 대체될 수 있다. "모듈"은 하나 또는 그 이상의 기능을 수행하는 최소 단위 또는 그 일부가 될 수도 있다. 도 1에서 바이너리 분석 모듈(112), 결함 분석 모듈(114), 결함 탐지 모듈(116), 및 크래쉬 모니터링 모듈(118)은 서로 분리된 별개의 것으로 도시되어 있지만, 도시된 것으로 한정되지는 않는다. 일 실시예에서, 바이너리 분석 모듈(112), 결함 분석 모듈(114), 결함 탐지 모듈(116), 및 크래쉬 모니터링 모듈(118)은 하나의 모듈 또는 세개 이하의 복수의 모듈로 통합될 수 있다.
바이너리 분석 모듈(112)은 컴퓨터 시스템(100)에 의해 실행되는 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable)를 포함하는 정적 메모리(static memory) 정보를 추출할 수 있다. 일 실시예에서, 바이너리 분석 모듈(112)은 애플리케이션이 컴퓨터 시스템(100) 상에서 실행되기 전에 미리 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다. 바이너리 분석 모듈(112)은 사용자 입력을 통해 애플리케이션이 실행되기 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기(analyzer)를 먼저 실행하도록 할 수 있다. 일 실시예에서, 바이너리 분석 모듈(112)은 상기 바이너리 분석기를 디폴트(default)로 실행하도록 설정할 수 있다.
바이너리 분석 모듈(112)은 애플리케이션의 ELF 파일의 코드를 분석하여 글로벌 변수와 로컬 변수를 추출할 수 있다. 바이너리 분석 모듈(112)은 추출된 글로벌 변수 및 로컬 변수를 저장부(130)에 저장할 수 있다. 일 실시예에서, 바이너리 분석 모듈(112)은 Windows의 PE 파일의 코드를 분석하여 글로벌 변수와 로컬 변수를 추출할 수 있다. 바이너리 분석 모듈(112)이 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하고, 저장부(130)에 저장하는 구체적인 방법은 도 3 내지 도 6의 설명 부분에서 상세하게 설명하기로 한다.
결함 탐지 모듈(116)은 바이너리 분석 모듈(112)에 의해 추출되고 저장부(130)에 저장된 글로벌 변수 및 로컬 변수 정보에 기초하여 메모리(120)의 결함을 탐지할 수 있다. 일 실시예에서, 결함 탐지 모듈(116)은 추출된 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소(address), 크기, 호출함수 중 적어도 하나를 분석하고, 분석 결과에 기초하여 메모리(120)의 결함 정보를 획득할 수 있다.
결함 탐지 모듈(116)은 Dynamic Binary Injection(DBI) 기술을 이용하여 애플리케이션이 실행 중에 메모리(120)의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링할 수 있다. 일 실시예에서, 결함 탐지 모듈(116)은 저장부(130)에 저장된 글로벌 변수 및 로컬 변수에 기초하여 메모리(120)의 글로벌 영역 및 스택 영역(Stack)의 메모리 결함을 검출하고, DBI 기술을 이용하여 메모리(120)의 Heap 영역에서의 함수 호출을 모니터링하여 메모리 결함을 검출할 수 있다. 스택 영역에는 로컬 변수가 저장되어 있을 수 있다.
결함 탐지 모듈(116)은 메모리의 할당, 접근, 및 해제 관련 함수가 실행되는 경우, 저장부(130)에 저장된 메모리 주소 정보를 이용하여 메모리의 결함을 검출할 수 있다. 예를 들어, 결함 탐지 모듈(116)은 메모리 할당 함수의 파라미터 중 할당 크기에 해당하는 파라미터의 값이 '0'인 경우(zero-size 메모리 할당), 메모리 할당 함수의 실행 결과가 NULL인 경우(메모리 할당 실패), 및 애플리케이션이 종료된 이후 해제되지 않은 동적 메모리 할당이 있는 경우(메모리 누수) 중 적어도 하나의 경우 메모리 할당과 관련된 결함이 있는 것으로 판단할 수 있다.
또한, 결함 탐지 모듈(116)은 메모리 접근 함수의 주소 파라미터 값이 NULL인 경우(NULL 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그의 해제 flag 값이 설정되어 있는 경우(해제된 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그가 존재하지 않고, 스택 주소 공간에 해당되지 않는 경우(할당되지 않은 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그의 할당 크기의 범위를 벗어나는 경우(할당 범위를 벗어난 접근), 및 문자열 함수의 소스(source)에 해당되는 문자열에 ‘\0’ 처리가 되어 있지 않은 경우(다른 변수의 메모리 공간과 충돌) 중 적어도 하나의 경우에 메모리 접근과 관련된 결함이 있는 것으로 판단할 수 있다.
또한, 결함 탐지 모듈(116)은 메모리 해제 함수의 파라미터 값이 NULL인 경우(NULL 포인터 해제), 저장부(130) 내에 인포메이션 태그가 존재하지 않거나, 할당 flag의 값이 정적 할당에 해당하는 경우(할당되지 않은 포인터 해제), 인포메이션 태그의 할당 함수 유형 flag 값이 해제 함수의 유형과 불일치하는 경우(할당/해제 불일치), 및 저장부(130) 내의 인포메이션 태그 상의 해제 flag가 설정되어 있는 경우(해제된 메모리 재해제) 중 적어도 하나의 경우에 메모리 해제와 관련된 결함이 있는 것으로 판단할 수 있다.
크래쉬 모니터링 모듈(Crash Monitoring module)(118)은 애플리케이션이 실행 중에 메모리(120)에 잘못 할당, 접근, 해제되어 발생되는 크래쉬(crash)를 분석하여 크래쉬 관련 데이터를 수집할 수 있다. 크래쉬 모니터링 모듈(118)은 애플리케이션에 크래쉬가 발생하는 경우 크래쉬를 모니터링하도록 시그널을 후킹(hooking)할 수 있다. 일 실시예에서, 크래쉬 모니터링 모듈(118)은 애플리케이션에 크래쉬가 발생되어 애플리케이션이 종료되는 신호(signal)에 따라, 커널(kernel)의 시그널 핸들러(signal handler)를 크래쉬가 발생한 시점의 메모리 정보 및 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체할 수 있다. 크래쉬 모니터링 모듈(118)은 교체된 시그널 핸들러를 호출하고, 호출된 시그널 핸들러를 이용하여 크래쉬와 관련된 애플리케이션의 콜 스택(Call Stack) 정보를 수집할 수 있다. 크래쉬 모니터링 모듈(118)은 수집된 콜 스택 정보를 저장부(130)에 저장할 수 있다.
결함 분석 모듈(114)은 에이전트(110-2)로부터 획득된 로그 정보를 분석하여 메모리(120)의 결함 정보를 출력할 수 있다. 일 실시예에서, 결함 분석 모듈(114)은 결함 탐지 모듈(116)에서 검출한 메모리(120)의 글로벌 영역, 스택 영역, Heap 영역에서의 메모리 결함 정보 및 크래쉬 모니터링 모듈(118)에서 수집한 콜 스택 정보에 기초하여 메모리(120)의 오류 원인을 분석할 수 있다. 결함 분석 모듈(114)은 메모리 오류가 어느 위치에서 발생되었는지, 또는 메모리 세팅(setting), 버퍼 오류, 참조 번지 오류 등을 포함하는 메모리 오류의 원인을 분석할 수 있다. 결함 분석 모듈(114)은 분석된 결과를 텍스트 형태로 출력할 수 있다.
메모리(120)는 컴퓨터 시스템(100)의 적어도 하나의 구성 요소에 관계된 명령어(instruction) 또는 데이터를 저장할 수 있다. 메모리(120)는 예를 들어, DRAM(dynamic RAM), SRAM(static RAM), 또는 SDRAM(synchronous dynamic RAM)으로 구성될 수 있지만, 이에 한정되는 것은 아니다.
일 실시예에서,　메모리(120)는 소프트웨어 및/또는 프로그램을 저장하는 비휘발성 메모리를 포함할 수 있다. 프로그램은 예를 들어, 커널(kernel), 라이브러리 및 애플리케이션을 포함할 수 있지만, 이에 한정되지는 않는다. 메모리(120)에는 미들웨어(middleware) 및 API(Application Programming Interface)이 저장되어 있을 수 있다.
저장부(130)는 프로세서(110)에서 검출한 메모리 오류 정보를 저장할 수 있다. 저장부(130)는 플래시　메모리(예: NAND flash 또는 NOR flash 등), 하드 드라이브, 및 솔리드 스테이트 드라이브(solid state drive(SSD)) 중 어느 하나로 구성될 수 있다. 다만, 저장부(130)가 나열된 예시로 구성되는 것으로 한정되지는 않는다.
저장부(130)는 바이너리 분석 모듈(112)에서 추출한 애플리케이션의 글로벌 변수 및 로컬 변수를 포함하는 정적 메모리 정보를 저장하는 인포메이션 태그 저장부(information tag repository)를 포함할 수 있다. 일 실시예에서, 저장부(130)는 결함 탐지 모듈(116)에서 분석한 메모리(120)의 Heap 영역에서의 결함 정보를 로그(log) 형태로 저장할 수 있다. 일 실시예에서, 저장부(130)는 크래쉬 모니터링 모듈(118)에서 수집한 콜 스택 정보를 애플리케이션 크래쉬 로그 형태로 저장하고, 커널 자체에서 발생된 크래쉬를 분석한 데이터를 커널 크래쉬 로그로 저장할 수 있다. 이에 대해서는 도 10의 설명 부분에서 상세하게 설명하기로 한다.
도 2는 본 개시의 일 실시예에 따른 컴퓨터 시스템(100)이 메모리 오류를 검출하는 방법을 도시한 흐름도이다.
단계 S210에서, 컴퓨터 시스템(100)은 애플리케이션의 실행 이전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출한다. 일 실시예에서, 컴퓨터 시스템(100)은 사용자 입력에 따라 애플리케이션이 실행되기 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기(Analyer)를 먼저 실행되도록 설정하고, 실행된 바이너리 분석기를 통해 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다. 일 실시예에서, 컴퓨터 시스템(100)은 애플리케이션의 ELF 파일의 코드를 분석하여 애플리케이션의 글로벌 변수와 로컬 변수를 추출할 수 있다. 일 실시예에서, 컴퓨터 시스템(100)은 추출된 글로벌 변수 및 로컬 변수 각각의 주소(address), 크기, 호출 함수 중 적어도 하나를 분석할 수 있다.
단계 S220에서, 컴퓨터 시스템(100)은 추출된 애플리케이션의 글로벌 변수 및 로컬 변수를 인포메이션 태그 저장부(information tag repository)에 저장한다. 인포메이션 태깅(information tagging)은 글로벌 변수 및 로컬 변수에 관한 정보(주소, 크기)와 동적으로 할당, 접근, 해제되는 Heap 영역의 정보(주소, 크기, 할당 함수 콜 스택, 해제 함수 콜 스택, 할당 함수 유형)를 메모리 공간에 저장하는 방법을 의미한다. 이에 대해서는 도 6의 설명 부분에서 상세하게 설명하기로 한다.
단계 S230에서, 컴퓨터 시스템(100)은 저장된 글로벌 변수 및 로컬 변수 정보와 애플리케이션의 실행 중에 수집된 동적 메모리 정보에 기초하여 메모리 오류를 검출한다. 일 실시예에서, 컴퓨터 시스템(100)은 인포메이션 태그 저장부에 저장된 애플리케이션의 글로벌 변수 및 로컬 변수 정보에 기초하여 정적 메모리 영역의 결함을 탐지할 수 있다.
컴퓨터 시스템(100)은 또한, Dynamic Binary Injection(DBI) 기술을 이용하여 애플리케이션이 실행 중에 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링할 수 있다. 즉, 컴퓨터 시스템(100)은 인포메이션 태그 저장부에 저장된 글로벌 변수 및 로컬 변수에 기초하여 메모리의 글로벌 영역 및 스택 영역(Stack)의 메모리 결함을 검출하고, DBI 기술을 이용하여 메모리의 Heap 영역에서의 함수 호출을 모니터링하여 메모리 결함을 검출할 수 있다.
일 실시예에서, 컴퓨터 시스템(100)은 애플리케이션이 실행 중에 잘못된 메모리 참조(memory corruption) 등으로 인하여 크래쉬가 발생되는 경우, 크래쉬를 모니터링하도록 시그널을 후킹(hooking)할 수 있다. 컴퓨터 시스템(100)은 애플리케이션의 크래쉬가 발생한 시점의 메모리 정보 및 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하고, 크래쉬와 관련된 콜 스택(Call Stack) 정보를 수집할 수 있다.
컴퓨터 시스템(100)은 인포메이션 태그 저장부에 저장된 애플리케이션의 글로벌 변수와 로컬 변수로 인한 정적 메모리 영역에서의 결함 정보, 애플리케이션 실행 중에 동적으로 할당, 접근, 해제되는 동적 메모리 영역에서의 결함 정보, 및 콜 스택 정보를 기초로 메모리의 오류를 검출하고, 오류 원인을 분석할 수 있다. 일 실시예에서, 컴퓨터 시스템(100)은 분석 결과를 텍스트 형태로 출력할 수 있다.
종래의 메모리 오류를 검출하는 기술들은 애플리케이션의 실행 시점에 메모리 검출 도구가 탑재되기 때문에 메모리 검출 도구의 탑재 이후 시점에서 접근, 할당, 및 해제되는 동적 메모리 오류는 분석 가능하지만, 애플리케이션의 실행 이전에 할당이 완료된 글로벌 변수 및 스택 영역에 할당되는 로컬 변수에 대해서는 정보를 획득할 수 없어 메모리의 글로벌 영역 및 스택 영역에서 발생되는 메모리 오류는 검출해낼 수 없는 문제점이 있었다. 또한, 시스템 상에서 메모리 오류가 발생한다 하더라도 애플리케이션이 의도하지 않은 방향으로 계속적으로 실행될 수 있으며, 애플리케이션의 크래쉬가 발생되어 종료되는 경우 종료 시점에서의 메모리 오류의 원인에 관한 정보를 알 수 없어 프로그램 오류를 수정하는데 어려움이 있었다.
도 1 및 도 2에 도시된 실시예에 따른 컴퓨터 시스템 및 메모리 오류 검출 방법은 애플리케이션의 실행으로 인하여 동적으로 할당, 접근, 해제되는 동적 메모리 정보에 의한 오류를 검출할 뿐만 아니라, 애플리케이션이 실행되기 전에 미리 애플리케이션의 글로벌 변수 및 로컬 변수와 같은 정적 메모리 정보를 추출하고, 추출된 정적 메모리 정보를 이용하여 메모리의 오류를 검출함으로써, 메모리 오류 검출의 정확성을 향상시킬 수 있다. 또한, 본 개시의 실시예에 따른 컴퓨터 시스템 및 메모리 오류 검출 방법은, 애플리케이션의 크래쉬가 발생하는 경우 크래수의 발생 시점의 메모리 정보 및 크래쉬 발생 이전까지의 메모리 결함 정보를 모니터링한 결과를 분석하고, 분석된 결과를 출력함으로써 사용자가 메모리 오류의 원인을 정확하게 파악할 수 있도록 할 수 있다.
또한, 본 개시의 실시예에 따른 컴퓨터 시스템 및 메모리 오류 검출 방법은 별도의 하드웨어 장비의 추가 없이, 소프트웨어 적인 방법으로 메모리의 결함 탐지 및 오류 분석이 가능하므로, 추가 비용 및 공간이 필요하지 않아 효율적이다. 또한, 종래의 DBI (Dynamic Binary Injection) 기법을 활용하므로, 실행 바이너리의 변경이 필요하지 않다.
도 3은 애플리케이션의 실행 파일인 ELF 파일(300)의 구조를 도시한 개념도이고, 도 4는 애플리케이션의 글로벌 변수의 정보를 추출하는데 사용하는 프로그램 코드(400)의 일 례를 도시한 도면이다.
도 3을 참조하면, 리눅스(Linux) 또는 유닉스(UNIX)에서 사용하는 실행 파일인 ELF 파일(300)에는 애플리케이션의 실행 명령어를 적재하는 영역인 텍스트 영역(310), 애플리케이션이 실행되는데 있어 필요한 변수가 저장되는 데이터 영역(320), 및 초기화되지 않은 데이터 영역인 BSS 영역(330)을 포함될 수 있다. 데이터 영역(320)에는 초기화된 변수가 저장되고, 애플리케이션이 종료될 때까지 메모리 상에 상주할 수 있다.
데이터 영역(320) 및 BSS 영역(330)에 글로벌 변수가 저장되어 있다. 컴퓨터 시스템은 ELF 파일(300)의 데이터 영역(320) 및 BSS 영역(330)에 저장된 글로벌 변수 정보 중 주소(address)와 크기를 추출할 수 있다. 일 실시예에서, 컴퓨터 시스템이 Windows 기반인 경우, Windows의 실행 파일 포맷인 PE 파일을 통해 글로벌 변수 정보를 추출할 수 있다.
컴퓨터 시스템의 바이너리 분석 모듈(112, 도 1 참조)은 도 4에 도시된 프로그램 코드(400)에 따라 ELF 파일에서 글로벌 변수 정보를 추출할 수 있다. 도 4는 애플리케이션의 글로벌 변수를 추출하는 프로그램 코드(400)의 일 례를 도시한 것이고, 본 개시의 실시예가 도시된 프로그램 코드로 한정되는 것은 아니다. 바이너리 분석 모듈(112)은 프로그램 코드(400)와 같이 buffer(410)라는 글로벌 변수를 작성하고, ELF 헤더(ELF header)를 분석하여 ELF 파일(300, 도 3 참조)의 BSS 영역(330, 도 3 참조)의 글로벌 변수 주소 및 크기 정보를 추출할 수 있다.
도 5는 애플리케이션의 로컬 변수의 정보를 추출하는데 사용하는 프로그램 코드(500)의 일 례를 도시한 도면이다.
컴퓨터 시스템의 바이너리 분석 모듈(112, 도 1 참조)은 프로그램 코드(500)에 따라 ELF 파일의 텍스트 영역(.text 영역)에 저장되는 실행 코드(510)를 분석하여 로컬 변수(520)를 추출할 수 있다. 도 5는 애플리케이션의 글로벌 변수를 추출하는 프로그램 코드(500)의 일 례를 도시한 것이고, 본 개시의 실시예가 도시된 프로그램 코드로 한정되는 것은 아니다.
프로그램 코드(500)에 따르면, 메인 함수의 수행 시 스택 포인터(Stack pointer, SP)에 값을 추가 또는 삭제하는 연산을 수행할 수 있다. 바이너리 분석 모듈(112)은 프로그램 코드(500)의 스택 포인터 추가 또는 삭제 연산을 분석하여 로컬 변수(520)의 주소(address), 크기, 및 호출 함수 중 적어도 하나를 포함하는 로컬 변수 정보를 추출할 수 있다. 여기서, 스택(Stack)의 주소는 애플리케이션 실행 시에 변경되므로, 로컬 변수의 주소는 스택 포인터의 오프셋(offset)값으로 추출될 수 있다.
도 6은 인포메이션 태그(information tag)(600)에 저장되는 메모리 정보를 도식화한 도면이다.
도 6을 참조하면, 인포메이션 태그(600)는 정적 메모리 영역 및 동적 메모리 영역의 주소(610), 크기(620), 할당 플래그(630), 할당 함수 유형(640), 해제 플래그(650), 할당 Caller(660), 및 해제 Caller(670)의 정보를 포함할 수 있다. 인포메이션 태그(600)의 주소(610) 및 크기(620)에는 Heap 메모리 영역의 주소 및 크기에 관한 정보 뿐만 아니라, 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소와 크기가 저장될 수 있다.
일반적인 인포메이션 태그에는 특정 메모리 영역에 대한 기본 정보(예를 들어, 주소, 크기 등)만을 저장한다. 그러나, 본 개시의 일 실시예에 따른 인포메이션 태그(600)는 메모리 오류의 원인 분석을 용이하게 하기 위하여 Heap 메모리 영역에서의 할당 Caller(660) 및 해제 Caller(670)와 같은 부가적인 정보를 추가로 저장하도록 구성할 수 있다.
컴퓨터 시스템(100)은 인포메이션 태그(600)에 저장된 글로벌 변수 및 로컬 변수 각각의 주소(610)와 크기(620)를 참조하여 정적 메모리 영역의 오류를 검출할 수 있다. 또한, 컴퓨터 시스템(100)은 인포메이션 태그(600)를 이용하여 Heap 메모리 영역에 동적으로 할당, 접근, 및 해제된 함수의 호출 정보를 모니터링함으로써 동적 메모리 영역의 오류를 검출할 수 있다.
도 7은 본 개시의 일 실시예에 따른 메모리 오류 검출 시스템(700)의 구성 요소를 도시한 블록도이다. 메모리 오류 검출 시스템(700)은 컴퓨터 시스템 상에서 발생되는 메모리 오류를 검출하고, 메모리 오류의 원인을 분석하는 시스템으로서, 프로세서(110, 도 1 참조)에 의해 구현(implement)될 수 있다. 다만, 이에 한정되는 것은 아니고, 메모리 오류 검출 시스템(700)은 하드웨어 및 소프트웨어의 조합을 통해 구현될 수도 있다. 메모리 오류 검출 시스템(700)은 적어도 하나 이상의 기능을 수행하기 위한 모듈, 프로그램, 루틴(routine), 명령어 세트(sets of instructions), 및 프로세스 중 적어도 하나를 포함할 수 있다.
도 7을 참조하면, 메모리 오류 검출 시스템(700)은 애플리케이션(702), 라이브러리(704), 디바이스 드라이버(706), 및 운영 체제(708)를 포함할 수 있다.
애플리케이션(702)은 역 어셈블러(disassembler)(712), 바이너리 분석기(714), 메모리 결함 모니터(716), 및 적어도 하나의 프로세스(P 1 내지 P n)를 포함할 수 있다. 역 어셈블러(712)는 라이브러리(704), 컴파일된 오브젝트 모듈, 공유 오브젝트 파일, 또는 독립 실행 파일 등의 바이너리 파일들의 정보를 제공하고, ELF 파일을 어셈블리어로 나타낼 수 있다. 또한, 일 실시예에서 역 어셈블러(712)는 Windows 운영체제에서의 PE 파일을 역 어셈블하여 바이너리 파일들의 정보를 제공할 수 있다. 예를 들어, 역 어셈블러(712)는 Objdump와 같은 프로그램으로 구현될 수 있으나, 이에 한정되지는 않는다.
바이너리 분석기(714)는, 사용자 입력에 따라 애플리케이션이 실행되기 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하도록 구성될 수 있다. 바이너리 분석 모듈(710)은 역 어셈블러(712)를 이용하여 애플리케이션의 실행 파일인 ELF 파일을 역 어셈블(disassemble)시켜 바이너리 분석기(714)에 전달하고, 바이너리 분석기(714)는 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소(address)와 크기에 관한 정보를 추출할 수 있다. 일 실시예에서, 바이너리 분석기(714)는 애플리케이션의 실행 전에 미리 동작되도록 디폴트(default)로 설정될 수 있다. 바이너리 분석 모듈(710)은 추출된 글로벌 변수 및 로컬 변수의 주소와 크기에 관한 정보를 인포메이션 태그 저장부(734)에 저장할 수 있다. 바이너리 분석 모듈(710)은 도 1에 도시된 바이너리 분석 모듈(112)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
메모리 결함 모니터(716)는 애플리케이션 실행 시의 함수의 호출 관계를 분석하고, 트레이스 로그(trace log) 및 크래쉬 로그(crash log)를 분석하여 메모리 오류의 원인을 분석할 수 있다. 트레이스 로그 및 크래쉬 로그에 관해서는 도 10의 설명 부분에서 상세하게 설명하기로 한다.
일 실시예에서, 메모리 결함 모니터(716)는 결함 분석 모듈(720)에 의해 동작될 수 있다. 메모리 결함 모니터(716)는 인포메이션 태그 저장부(734)에 저장된 글로벌 변수 및 로컬 변수 정보에 기초하여 메모리의 글로벌 영역 및 스택 영역에서의 결함 정보를 분석할 수 있다. 또한, 메모리 결함 모니터(716)는 애플리케이션의 실행 시 메모리의 Heap 영역에 할당, 접근, 및 해제되는 함수 호출 정보에 기초하여 수집된 콜 스택 정보(Call Stack)를 통해 동적 메모리 결함 정보를 분석할 수 있다. 메모리 결함 모니터(716)는 메모리 오류가 어느 위치에서 발생되었는지, 또는 메모리 세팅(setting), 버퍼 오류, 참조 번지 오류 등을 포함하는 메모리 오류의 원인을 분석할 수 있다.
프로세스(process)는 컴퓨터 시스템 상에서 실행되는 애플리케이션의 단위를 의미할 수 있다. 예를 들어, 문서 작성 애플리케이션 프로그램의 실행 창 하나를 의미할 수 있다. 애플리케이션(702)은 적어도 하나의 프로세스(P 1 내지 P n)를 포함할 수 있다.
라이브러리(704)는 적어도 하나의 프로세스(P 1 내지 P n)가 공통적으로 필요로 하는 기능을 제공할 수 있다. 라이브러리(704)는 예를 들어 적어도 하나의 프로세스(P 1 내지 P n)의 입출력 관리, 메모리 관리, 또는 함수 호출에 관한 기능 등을 수행할 수 있다.
라이브러리(704)는 모니터링 라이브러리(MMonitor.so)(732) 및 사용자 부(742)를 포함할 수 있다. 모니터링 라이브러리(732)는 프로세스(P 1 내지 P n 중 어느 하나)가 실행됨에 따라 호출되고, 프로세스에 의해 메모리의 Heap 영역에 할당, 접근, 및 해제되는 함수 호출 정보를 추적할 수 있다. 일 실시예에서, 모니터링 라이브러리(732)는 결함 탐지 모듈(730)에 의해 호출될 수 있다. 일 실시예에서, 결함 탐지 모듈(730)은 메모리의 Heap 영역에 할당, 접근, 및 해제되는 함수 호출 정보를 인포메이션 태그 저장부(734)에 저장할 수 있다. 여기에서, 결함 탐지 모듈(730)은 인포메이션 태그 저장부(734)를 포함한다는 점을 제외하고는 도 1에 도시된 결함 탐지 모듈(116)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
사용자 부(742)는 디바이스 드라이버(706)를 제어하는 기능을 수행할 수 있다. 일 실시예에서, 사용자 부(742)는 적어도 하나의 프로세스(P 1 내지 P n) 중 어느 하나의 프로세스에서 크래쉬(crach)가 발생하는 경우 커널부(744)의 제어에 따라 콜 스택(Call Stack) 정보를 수집할 수 있다. 이에 대해서는 도 10의 설명 부분에서 구체적으로 설명하기로 한다.
디바이스 드라이버(706)는 커널부(744)를 포함할 수 있다. 커널부(744)는 메모리의 글로벌 영역, 스택 영역, 및 Heap 영역을 포함하는 메모리의 전체적인 상황 및 시스템 자원 현황을 모니터링할 수 있다. 커널부(744)는 커널(kernel)에서 크래쉬가 발생되는 경우 커널 크래쉬 정보를 수집하고, 수집된 커널 크래쉬 정보를 로그 형태로 저장할 수 있다.
일 실시예에서, 사용자 부(742) 및 커널부(744)는 크래쉬 모니터링 모듈(740)에 의해 동작될 수 있다. 크래쉬 모니터링 모듈(740)은 도 1에 도시된 크래쉬 모니터링 모듈(118)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
운영 체제(708)는 리눅스(Linux), 유닉스(UNIX), 및 윈도우(Windows) 중 어느 하나일 수 있으나, 나열된 예시로 한정되는 것은 아니다.
도 8은 본 개시의 일 실시예에 따른 컴퓨터 시스템이 메모리의 글로벌 영역, 스택 영역 및 Heap 영역 중 적어도 하나의 영역에서의 메모리 결함을 검출하는 방법을 도시한 흐름도이다.
단계 S810에서, 컴퓨터 시스템은 애플리케이션의 글로벌 변수 및 로컬 변수를 추출한다. 일 실시예에서, 컴퓨터 시스템은 애플리케이션이 실행되기 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기(Analyer)를 먼저 실행되도록 설정하고, 실행된 바이너리 분석기를 통해 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다. 일 실시예에서, 컴퓨터 시스템은 애플리케이션의 ELF 파일의 코드를 분석하여 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소(address), 크기, 호출 함수 중 적어도 하나를 추출할 수 있다.
일 실시예에서, 컴퓨터 시스템은 추출된 글로벌 변수 및 로컬 변수를 인포메이션 태그 저장부(information tag repository)에 저장할 수 있다.
단계 S820에서, 컴퓨터 시스템은 애플리케이션을 실행한다. 애플리케이션은 사용자의 실행 지시가 입력됨에 따라 실행될 수 있다. 하나의 애플리케이션이 실행되면 컴퓨터 시스템은 하나의 프로세스(process)로 인식할 수 있다. 즉, 프로세스는 컴퓨터 시스템 상에서 실행되는 애플리케이션의 단위를 의미할 수 있다. 예를 들어, 문서 작성 애플리케이션 프로그램의 실행 창 하나를 의미할 수 있다.
단계 S830에서, 컴퓨터 시스템은 메모리의 Heap 영역에서 동적으로 할당, 접근, 및 해제되는 동적 메모리 정보를 모니터링한다. 일 실시예에서, 컴퓨터 시스템은 단계 S820에서 실행된 애플리케이션에 의해 프로세스가 수행되는 즉시 라이브러리에서 MMonitoring.so를 호출하고, 호출된 MMonitoring.so를 이용하여 메모리의 Heap 영역에 할당, 접근, 및 해제되는 함수 호출 정보를 추적(trace)할 수 있다. 일 실시예에서, 컴퓨터 시스템은 DBI(Dynamic Binary Injection) 기법을 이용하여 프로세스 수행 중에 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링할 수 있다.
단계 S840에서, 컴퓨터 시스템은 메모리의 글로벌 영역, 스택 영역, 및 Heap 영역 중 적어도 하나의 영역에서의 메모리 결함을 검출한다. 일 실시예에서, 컴퓨터 시스템은 인포메이션 태그 저장부에 저장된 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소, 크기, 및 호출함수 중 적어도 하나에 기초하여 글로벌 영역 및 스택 영역에서의 결함을 탐지할 수 있다. 일 실시예에서, 컴퓨터 시스템은 DBI 기법을 이용하여 메모리의 Heap 영역에서의 함수 호출을 모니터링하여 동적 메모리 영역에서의 결함을 검출할 수 있다.
도 9는 본 개시의 일 실시예에 따른 컴퓨터 시스템이 시그널 핸들러를 교체하여 동적 메모리 영역의 오류의 원인을 검출하고, 이를 분석하는 방법을 도시한 흐름도이다.
단계 S910에서, 컴퓨터 시스템은 커널(kernel)의 시그널 핸들러(signal handler)를 애플리케이션에 의한 크래쉬 발생을 모니터링 하는 시그널 핸들러로 교체한다. 일 실시예에서, 컴퓨터 시스템은 사용자 모드(user mode)에서 애플리케이션이 실행되기 전에 시그널 핸드러를 미리 교체할 것을 커널에 요청할 수 있다. 이 경우, 커널은 기설정된 시그널 핸들러를 애플리케이션에 크래쉬가 발생된 시점의 메모리 정보 및 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체할 수 있다.
단계 S920에서, 컴퓨터 시스템은 교체된 시그널 핸들러를 호출한다. 컴퓨터 시스템 상에서 실행되는 애플리케이션에 의한 프로세스 동작 도중 메모리 커럽션(memory corruption) 등으로 인한 크래쉬(crash)가 발생되면 커널에서 단계 S910에서 교체된 시그널 핸들러가 대신 호출된다. 즉, 커널은 프로세스에 크래쉬가 발생했다는 신호(signal)에 응답하여 교체된 시그널 핸들러를 호출할 수 있다.
단계 S930에서, 컴퓨터 시스템은 콜 스택(Call Stack) 정보를 수집한다. 일 실시예에서, 컴퓨터 시스템은 커널에서 호출된 시그널 핸들러를 이용하여 프로세스에서 발생된 크래쉬와 관련된 정보를 분석할 수 있는 콜 스택 정보를 수집할 수 있다. 콜 스택 정보는 프로세스에 의해 메모리에 변수를 할당하거나, 접근, 해제하는 함수 호출에 관한 이력 정보(history)를 의미할 수 있다.
단계 S940에서, 컴퓨터 시스템은 수집된 콜 스택 정보에 기초하여 메모리 오류의 원인을 분석한다. 일 실시예에서, 컴퓨터 시스템은 수집된 콜 스택 정보에 기초하여 동적 메모리 영역의 오류 발생 위치, 메모리 세팅(setting), 버퍼 오류, 참조 번지 오류 등을 포함하는 메모리 오류의 원인을 분석할 수 있다.
일 실시예에서, 컴퓨터 시스템은 콜 스택 정보를 통해 획득한 메모리 오류 원인 정보를 애플리케이션 크래쉬 로그(application crash log)로 저장할 수 있다.
도 10은 본 개시의 일 실시예에 따른 컴퓨터 시스템이 애플리케이션으로 인한 메모리 오류를 검출하는 방법을 도시한 흐름도이다. 도 10을 참조하면, 컴퓨터 시스템의 오류 검출 모드는, 애플리케이션을 실행하고, 실행된 애플리케이션에 의한 메모리 오류를 검출하는 사용자 모드(1001) 및 애플리케이션에서 구현되는 동작 또는 기능을 실행하는데 사용되는 시스템 리소스를 제어/관리하는 커널 모드(1002)를 포함할 수 있다. 커널 모드는 리눅스(Linux) 또는 유닉스(UNIX)와 같은 운영 체제에서 동작되는 모드일 수 있다. 그러나, 커널 모드가 동작되는 운영 체제가 리닉스 또는 유닉스로 한정되는 것은 아니다.
단계 S1011에서, 컴퓨터 시스템은 애플리케이션의 글로벌 변수 및 로컬 변수를 추출한다. 일 실시예에서, 컴퓨터 시스템은 애플리케이션이 실행되기 전에 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기를 먼저 실행하고, 실행된 바이너리 분석기를 통해 애플리케이션의 글로벌 변수 및 로컬 변수를 추출할 수 있다. 일 실시예에서, 컴퓨터 시스템은 애플리케이션의 ELF 파일의 코드를 분석하여 애플리케이션의 글로벌 변수와 로컬 변수 각각의 주소(address), 크기, 호출 함수 중 적어도 하나를 분석할 수 있다.
단계 S1012에서, 컴퓨터 시스템은 추출된 애플리케이션의 글로벌 변수 및 로컬 변수를 인포메이션 태그 저장부(information tag repository)(1050)에 저장한다. 인포메이션 태그 저장부(1050)는 글로벌 변수 및 로컬 변수 각각의 주소 및 크기에 관한 정보를 저장할 수 있다. 단계 S1011 및 단계 S1012는 바이너리 분석 모듈(1010)에 의해 수행될 수 있다. 바이너리 분석 모듈(1010)은 도 1에 도시된 바이너리 분석 모듈(112)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
단계 S1013에서, 컴퓨터 시스템은 크래쉬 모니터링 모듈(crash monitoring module)을 커널에 삽입(injection)한다.
단계 S1014에서, 컴퓨터 시스템은 시그널 핸들러(signal handler)를 교체할 것을 커널에 요청하고, 단계 S1041에서 커널은 시그널 핸들러를 교체한다. 일 실시예에서, 사용자 모드(1001)에서는 커널의 시그널 핸들러를 애플리케이션에 의한 크래쉬 발생을 모니터링하는 시그널 핸들러로 교체할 것을 커널에 요청할 수 있다. 사용자 모드(1001)의 시그널 핸들러 교체 요청은 애플리케이션이 실행되는 단계(S1015) 이전에 수행될 수 있다. 즉, 컴퓨터 시스템은 사용자 모드(1001)에서 애플리케이션이 실행되기 전에 시그널 핸드러를 미리 교체할 것을 커널에 요청할 수 있다.
이 경우, 커널은 기설정된 시그널 핸들러를 애플리케이션에 크래쉬가 발생된 시점의 메모리 정보 및 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체할 수 있다(단계 S1041).
단계 S1015에서, 컴퓨터 시스템은 애플리케이션을 실행한다. 애플리케이션은 사용자 모드(1001)에서 사용자의 실행 지시가 입력됨에 따라 실행될 수 있다. 하나의 애플리케이션이 실행되면 컴퓨터 시스템은 하나의 프로세스(process)로 인식할 수 있다. 즉, 프로세스는 컴퓨터 시스템 상에서 실행되는 애플리케이션의 단위를 의미할 수 있다.
단계 S1031에서, 컴퓨터 시스템은 DBI(Dynamic Binary Injection) 방법을 통해 동적 메모리 영역의 할당, 해제, 접근 함수의 호출 정보를 수집한다. 일 실시예에서, 컴퓨터 시스템은 사용자 모드(1001)에서 애플리케이션이 실행되는 즉시 라이버러리에서 MMonitoring.so를 호출하고, 호출된 MMonitoring.so를 이용하여 메모리의 Heap 영역에 할당, 접근, 및 해제되는 함수 호출 정보를 추적(trace)할 수 있다. 일 실시예에서, 컴퓨터 시스템은 함수 호출 정보를 인포메이션 태그 저장부(1050)에 저장할 수 있다. 이 경우, 인포메이션 태그 저장부(1050)는 글로벌 변수 및 로컬 변수를 포함하는 정적 메모리 정보 뿐만 아니라, 동적으로 할당, 접근, 해제되는 Heap 영역의 정보(예를 들어, 주소, 크기, 할당 함수 콜 스택, 해제 함수 콜 스택, 할당 함수 유형)를 저장할 수 있다.
단계 S1032에서, 컴퓨터 시스템은 글로벌 영역, 스택 영역, 및 Heap 영역의 메모리 결함을 검출한다. 일 실시예에서, 컴퓨터 시스템은 DBI 방법을 이용하여 애플리케이션의 실행에 의해 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링하고, Heap 영역에서의 메모리 결함을 탐지할 수 있다.
일 실시예에서, 컴퓨터 시스템은 인포메이션 태그 저장부(1050)에 저장된 애플리케이션의 글로벌 변수 및 로컬 변수 각각의 주소, 크기, 및 호출함수 중 적어도 하나에 기초하여 글로벌 영역 및 스택 영역에서의 결함을 탐지할 수 있다.
컴퓨터 시스템은 메모리의 할당, 접근, 및 해제 관련 함수가 실행되는 경우, 인포메이션 태그 저장부(1050)에 저장된 메모리 주소 정보 또는 크기 정보를 이용하여 메모리의 결함을 검출할 수 있다. 예를 들어, 컴퓨터 시스템은 메모리 할당 함수의 파라미터 중 할당 크기에 해당하는 파라미터의 값이 ‘0’인 경우(zero-size 메모리 할당), 메모리 할당 함수의 실행 결과가 NULL인 경우(메모리 할당 실패), 및 애플리케이션이 종료된 이후 해제되지 않은 동적 메모리 할당이 있는 경우(메모리 누수) 중 적어도 하나의 경우 메모리 할당과 관련된 결함이 있는 것으로 판단할 수 있다.
또한, 컴퓨터 시스템은 메모리 접근 함수의 주소 파라미터 값이 NULL인 경우(NULL 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그의 해제 flag 값이 설정되어 있는 경우(해제된 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그가 존재하지 않고, 스택 주소 공간에 해당되지 않는 경우(할당되지 않은 포인터 접근), 접근하고자 하는 포인터에 대한 인포메이션 태그의 할당 크기의 범위를 벗어나는 경우(할당 범위를 벗어난 접근), 및 문자열 함수의 소스(source)에 해당되는 문자열에 ‘\0’ 처리가 되어 있지 않은 경우(다른 변수의 메모리 공간과 충돌) 중 적어도 하나의 경우에 메모리 접근과 관련된 결함이 있는 것으로 판단할 수 있다.
또한, 컴퓨터 시스템은 메모리 해제 함수의 파라미터 값이 NULL인 경우(NULL 포인터 해제), 인포메이션 태그 저장부(1050) 내에 인포메이션 태그가 존재하지 않거나, 할당 flag의 값이 정적 할당에 해당하는 경우(할당되지 않은 포인터 해제), 인포메이션 태그의 할당 함수 유형 flag 값이 해제 함수의 유형과 불일치하는 경우(할당/해제 불일치), 및 인포메이션 태그에 해제 flag가 설정되어 있는 경우(해제된 메모리 재해제) 중 적어도 하나의 경우에 메모리 해제와 관련된 결함이 있는 것으로 판단할 수 있다.
단계 S1033에서, 컴퓨터 시스템은 검출된 메모리 결함 정보를 트레이스 로그(1060)에 저장하고, 애플리케이션을 종료한다. 트레이스 로그(trace log)(1060)에는 메모리의 글로벌 영역 및 스택 영역은 물론이고, Heap 영역에서의 메모리 결함 정보를 저장하고 있을 수 있다.
단계 S1031 내지 단계 S1033은 결함 탐지 모듈(1030)에 의해 수행될 수 있다. 결함 탐지 모듈(1030)은 도 1에 도시된 결함 탐지 모듈(116)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
단계 S1042에서, 컴퓨터 시스템은 커널 모드(1002)에서 교체된 시그널 핸들러를 호출한다. 커널 모드(1002)는 사용자 모드(1001)에서 실행된 애플리케이션에서 메모리 커럽션(memory corruption) 등으로 인하여 애플리케이션에 크래쉬가 발생하였다는 시그널(signal)에 따라 단계 S1041에서 교체된 시그널 핸들러를 호출할 수 있다.
단계 S1043에서, 컴퓨터 시스템은 콜 스택(Call Stack) 정보를 수집한다. 일 실시예에서, 컴퓨터 시스템은 커널 모드(1002)에서 호출된 시그널 핸들러를 이용하여 애플리케이션에서 발생된 크래쉬와 관련된 정보를 분석할 수 있는 콜 스택 정보를 수집할 수 있다. 콜 스택 정보는 애플리케이션에 의해 메모리 상에 변수를 할당하거나, 접근, 해제하는 함수 호출에 관한 이력 정보(history)를 의미할 수 있다.
단계 S1044에서, 컴퓨터 시스템은 수집된 콜 스택 정보를 애플리케이션 크래쉬 로그(application crash log)(1071)에 저장한다. 애플리케이션 크래쉬 로그(1071)는 사용자 모드(1001)에서 실행된 애플리케이션에 의해 발생된 크래쉬와 관련된 콜 스택 정보를 저장할 수 있다.
단계 S1045에서, 커널은 커널 내에서 자체적으로 발생된 크래쉬와 관련된 분석 데이터를 수집한다. 커널 자체에서 발생되는 크래쉬는, 애플리케이션이 커널에 메모리 자원을 요청할 때 요청을 커널에서 수행될 수 없는 경우 발생될 수 있다. 예를 들어, 애플리케이션이 시스템 메모리에 접근하려고 하거나, 변수의 크기를 초과하여 변수를 할당하려고 하는 경우 등에서 커널 상에 크래쉬가 발생될 수 있다. 커널 모드(1002)에서는 크래쉬와 관련된 커널의 상태 정보, 예를 들어 글로벌 영역, 스택 영역, 및 Heap 영역을 포함하는 전체 메모리의 현재 상태 정보 또는 시스템의 자원 상황에 관련된 정보를 수집할 수 있다.
단계 S1046에서, 컴퓨터 시스템은 커널 크래쉬 로그(kernel crash log)(1072)에 크래쉬 분석 데이터를 저장하고, 종료된다. 커널 크래쉬 로그(1072)는 커널과 관련된 크래쉬 정보, 즉 수집된 시점에서의 전체 메모리의 상태 정보 또는 시스템의 자원 상황에 관련된 정보를 저장할 수 있다. 단계 S1046에서 종료되는 것은 커널 자체로써, 애플리케이션이 종료되는 단계 S1033 및 S1044와는 다르다.
단계 S1041 내지 단계 S1046은 크래쉬 모니터링 모듈(1040)에 의해 수행될 수 있다. 크래쉬 모니터링 모듈(1040)은 도 1에 도시된 크래쉬 모니터링 모듈(118)과 동일한 기능을 수행하는바, 중복되는 설명은 생략하기로 한다.
단계 S1021에서, 컴퓨터 시스템은 트레이스 로그(1060) 및 애플리케이션 크래쉬 로그(1071)에 저장된 정보에 기초하여 메모리 오류의 원인을 분석한다. 일 실시예에서, 컴퓨터 시스템은 트레이스 로그(1060)에 저장되어 있는 메모리의 글로벌 영역, 스택 영역, 및 Heap 영역에서의 메모리 결함 정보와 애플리케이션 크래쉬 로그(1071)에 저장되어 있는 콜 스택 정보를 통해 정적 및 동적 메모리의 오류 원인을 분석할 수 있다. 일 실시예에서, 컴퓨터 시스템은 메모리의 오류 발생 위치, 메모리 세팅(setting), 버퍼 오류, 참조 번지 오류 등의 메모리 오류 원인을 분석할 수 있다.
단계 S1022에서, 컴퓨터 시스템은 메모리 오류의 분석 결과를 출력한다.
도 11a는 할당되지 않은 포인터의 해제 결함으로 인한 메모리 오류를 분석하기 위한 프로그램 코드의 일 례를 도시한 도면이고, 도 11b는 인포메이션 태그 저장부에 저장된 메모리 정보를 도식화한 도면이다.
도 11a는 테스트 코드(1110)로서, 할당 함수인 malloc으로 동적 할당받아 사용하던 포인터 buf를 종료 전에 해제하여야 하는데, 글로벌 변수 buf가 해제 함수에 잘못 들어간 예를 도시한 도면이다. 일 실시예에서, 컴퓨터 시스템은 바이너리 분석을 통해 테스트 코드(1110) 분석을 하게 되며, 이를 통해 인포메이션 태그 저장부에 buf에 대한 정보(주소 0x00010070, 크기 0x64)를 저장할 수 있다. 테스트 코드(1110)의 분석을 통해 buf에 관한 정보를 추출하고, 추출된 정보를 인포메이션 태그 저장부에 저장하는 동작들은 바이너리 분석 모듈(112, 도 1 참조)에 의해 수행될 수 있다.
컴퓨터 시스템은 인포메이션 태깅(Information Tagging)을 이용하여 메모리 영역에서의 결함을 탐지한다. 컴퓨터 시스템은 tc_free_main 함수에서 메모리 관련 함수가 실행될 때마다 에이전트에서 정보를 수집할 수 있다. 일 실시예에서, 결함 탐지 모듈(116, 도 1 참조)은 테스트 코드(1110)의 4번째 줄에 기재된 'int* buf = (int*)malloc(sizeof(int))' 구문(1112)의 malloc 함수가 호출될 때 에이전트의 malloc 함수를 먼저 호출할 수 있다. 상기 구문(1112)의 경우 할당 파라미터 값에는 문제가 없으므로, 결함 탐지 모듈(116)은 원래의 malloc 함수를 호출하고, 그 결과가 NULL 값이 아닌 경우 인포메이션 태그 저장부에 저장할 수 있다.
바이너리 분석 모듈(112) 및 결함 탐지 모듈(116)에 의해 인포메이션 태그 저장부(1120)에 저장된 정보는 도 11b와 같다.
컴퓨터 시스템은 테스트 코드(1110)의 6번째 줄의 free 구문(1114) 호출 시 에이전트의 free 함수를 호출할 수 있다. 이 경우, 해제하고자 하는 메모리 주소가 buf의 주소인 0x10070으로 넘어오게 되고, 에이전트에서는 인포메이션 태그 저장부를 탐색하여 해당 값의 존재 여부를 확인할 수 있다. buf가 인포메이션 태그 저장부에 존재하는 값이므로, 결함 탐지 모듈(116, 도 1 참조)은 인포메이션 태그 저장부의 할당 flag를 먼저 확인하고, 0x10070의 할당 flag 값은 정적 할당을 의미하는 0x1이므로 '할당되지 않은 포인터 해제' 결함으로 판정할 수 있다. 결함 탐지 모듈(116)은 할당되지 않은 포인터 해제에 관련된 로그를 트레이스 로그(trace log)로 저장하고, 코드를 종료할 수 있다.
컴퓨터 시스템은 결함 탐지 모듈(118, 도 1 참조)에서 트레이스 로그를 분석하여 '할당되지 않은 포인터 해제' 결함이 발생한 소스 코드의 위치와 결함 로그를 분석할 수 있다. 또한, 컴퓨터 시스템은 인포메이션 태그 저장부에 buf에 대한 인포메이션 태그가 해제되지 않은 채로 남아 있는 경우 메모리 누수로 판정할 수 있다. 상기 결함 로그 분석 및 메모리 누수 판정 동작들은 결함 분석 모듈(114, 도 1 참조)에서 수행될 수 있다.
결함 분석 모듈(114)은 분석된 결함 또는 메모리 오류 원인을 텍스트 형태로 출력할 수 있다.
본 명세서에서 설명된 컴퓨터 시스템 및 컴퓨터 시스템에서 수행하는 메모리 오류 검출 방법은 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다.
소프트웨어는, 컴퓨터로 읽을 수 있는 저장 매체(computer-readable storage media)에 저장된 명령어를 포함하는 컴퓨터 프로그램으로 구현될 수 있다. 컴퓨터가 읽을 수 있는 기록 매체로는, 예를 들어 마그네틱 저장 매체(예컨대, ROM(read-only memory), RAM(random-access memory), 플로피 디스크, 하드 디스크 등) 및 광학적 판독 매체(예컨대, 시디롬(CD-ROM), 디브이디(DVD: Digital Versatile Disc)) 등이 있다. 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템들에 분산되어, 분산 방식으로 컴퓨터가 판독 가능한 코드가 저장되고 실행될 수 있다. 매체는 컴퓨터에 의해 판독가능하며, 메모리에 저장되고, 프로세서에서 실행될 수 있다.
컴퓨터로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 신호(signal)를 포함하지 않으며 실재(tangible)한다는 것을 의미할 뿐 데이터가 저장매체에 반영구적 또는 임시적으로 저장됨을 구분하지 않는다.
또한, 본 명세서에 개시된 실시예들에 따른 컴퓨터 시스템 및 컴퓨터 시스템에서 메모리 오류를 검출하는 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다.
컴퓨터 프로그램 제품은 소프트웨어 프로그램, 소프트웨어 프로그램이 저장된 컴퓨터로 읽을 수 있는 저장 매체를 포함할 수 있다. 예를 들어, 컴퓨터 프로그램 제품은 전자 장치의 제조사 또는 전자 마켓(예를 들어, 구글 플레이 스토어, 앱 스토어)을 통해 전자적으로 배포되는 소프트웨어 프로그램 형태의 상품(예를 들어, 다운로드 가능한 애플리케이션(downloadable application))을 포함할 수 있다. 전자적 배포를 위하여, 소프트웨어 프로그램의 적어도 일부는 저장 매체에 저장되거나, 임시적으로 생성될 수 있다. 이 경우, 저장 매체는 제조사의 서버, 전자 마켓의 서버, 또는 소프트웨어 프로그램을 임시적으로 저장하는 중계 서버의 저장매체가 될 수 있다.
컴퓨터 프로그램 제품은, 서버 및 단말(예로, 초음파 진단 장치)로 구성되는 시스템에서, 서버의 저장매체 또는 단말의 저장매체를 포함할 수 있다. 또는, 서버 또는 단말과 통신 연결되는 제3 장치(예, 스마트폰)가 존재하는 경우, 컴퓨터 프로그램 제품은 제3 장치의 저장매체를 포함할 수 있다. 또는, 컴퓨터 프로그램 제품은 서버로부터 단말 또는 제3 장치로 전송되거나, 제3 장치로부터 단말로 전송되는 소프트웨어 프로그램 자체를 포함할 수 있다.
이 경우, 서버, 단말 및 제3 장치 중 하나가 컴퓨터 프로그램 제품을 실행하여 개시된 실시예들에 따른 방법을 수행할 수 있다. 또는, 서버, 단말 및 제3 장치 중 둘 이상이 컴퓨터 프로그램 제품을 실행하여 개시된 실시예들에 따른 방법을 분산하여 실시할 수 있다.
예를 들면, 서버(예로, 클라우드 서버 또는 인공 지능 서버 등)가 서버에 저장된 컴퓨터 프로그램 제품을 실행하여, 서버와 통신 연결된 단말이 개시된 실시예들에 따른 방법을 수행하도록 제어할 수 있다.
또 다른 예로, 제3 장치가 컴퓨터 프로그램 제품을 실행하여, 제3 장치와 통신 연결된 단말이 개시된 실시예에 따른 방법을 수행하도록 제어할 수 있다.
제3 장치가 컴퓨터 프로그램 제품을 실행하는 경우, 제3 장치는 서버로부터 컴퓨터 프로그램 제품을 다운로드하고, 다운로드된 컴퓨터 프로그램 제품을 실행할 수 있다. 또는, 제3 장치는 프리로드된 상태로 제공된 컴퓨터 프로그램 제품을 실행하여 개시된 실시예들에 따른 방법을 수행할 수도 있다.
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 컴퓨터 시스템 또는 모듈 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

Claims (15)

  1. 컴퓨터 시스템에서 발생되는 메모리 오류를 검출하는 방법에 있어서,
    애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 단계;
    추출된 상기 글로벌 변수 및 상기 로컬 변수 정보를 인포메이션 태그 저장부(information tag repository)에 저장하는 단계; 및
    상기 인포메이션 태그 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보와 상기 애플리케이션이 실행 중에 수집된 동적 메모리(dynamic memory) 정보에 기초하여 메모리 오류를 검출하는 단계;
    를 포함하는, 방법.
  2. 제1 항에 있어서,
    상기 글로벌 변수 및 로컬 변수 정보를 추출하는 단계는, 사용자 입력에 따라 상기 애플리케이션이 실행되기 전에 상기 애플리케이션의 정적 메모리 정보를 추출하는 바이너리 분석기를 실행하도록 설정하고, 상기 바이너리 분석기를 통해 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는, 방법.
  3. 제1 항에 있어서,
    상기 메모리 오류를 검출하는 단계는, DBI(Dynamic Binary Injection) 기법을 통해 상기 실행 중인 애플리케이션에 의해 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 상기 동적 메모리 정보를 모니터링하는 단계를 포함하는, 방법.
  4. 제1 항에 있어서,
    상기 애플리케이션에 크래쉬(crash)가 발생되어 상기 애플리케이션이 종료되는 신호에 따라, 커널(kernel)의 시그널 핸들러(signal handler)를 상기 크래쉬가 발생한 시점의 메모리 정보 및 상기 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체하는 단계; 를 더 포함하는, 방법.
  5. 제4 항에 있어서,
    상기 교체된 시그널 핸들러를 호출하는 단계; 및
    호출된 시그널 핸들러를 이용하여 상기 크래쉬와 관련된 애플리케이션의 콜 스택(Call Stack) 정보를 수집하는 단계;
    를 더 포함하는, 방법.
  6. 제5 항에 있어서,
    상기 메모리 오류를 검출하는 단계는, 메모리의 글로벌 영역, 스택 영역, Heap 영역에서의 메모리 결함 정보 및 상기 수집된 콜 스택 정보에 기초하여 상기 메모리 오류의 원인을 분석하는, 방법.
  7. 메모리 오류를 검출하는 컴퓨터 시스템에 있어서,
    메모리; 및
    상기 컴퓨터 시스템에 의해 수행되는 애플리케이션이 상기 메모리를 참조함에 따라 발생되는 메모리 오류를 검출하는 프로세서;
    를 포함하고,
    상기 프로세서는,
    상기 애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 바이너리 분석 모듈;
    추출된 상기 글로벌 변수 및 상기 로컬 변수 정보에 기초하여 상기 메모리의 결함을 탐지하는 결함 탐지 모듈; 및
    상기 탐지된 메모리 결함에 기초하여 상기 메모리 오류를 검출하고, 검출된 오류를 분석하는 결함 분석 모듈; 을 포함하는, 컴퓨터 시스템.
  8. 제7 항에 있어서,
    상기 바이너리 분석 모듈은 사용자 입력에 따라 상기 애플리케이션이 실행되기 전에 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는 바이너리 분석기가 실행되도록 설정하고, 상기 바이너리 분석기를 통해 상기 애플리케이션의 글로벌 변수 및 로컬 변수를 추출하는, 컴퓨터 시스템.
  9. 제7 항에 있어서,
    상기 추출된 정적 메모리 정보를 저장하는 저장부;
    를 더 포함하고,
    상기 결함 탐지 모듈은 상기 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보에 기초하여 상기 메모리의 결함을 탐지하는, 컴퓨터 시스템.
  10. 제7 항에 있어서,
    상기 결함 탐지 모듈은 DBI(Dynamic Binary Injection) 기법을 사용하여 상기 애플리케이션이 실행 중에 상기 메모리의 Heap 영역에서 동적으로 할당, 접근 및 해제되는 동적 메모리 정보를 모니터링하는, 컴퓨터 시스템.
  11. 제7 항에 있어서,
    상기 프로세서는, 상기 애플리케이션이 실행 중에 발생되는 크래쉬(crash)를 분석하여 상기 크래쉬 관련 데이터를 수집하는 크래쉬 모니터링 모듈; 을 더 포함하는, 컴퓨터 시스템.
  12. 제11 항에 있어서,
    상기 크래쉬 모니터링 모듈은 상기 애플리케이션에 크래쉬가 발생되어 상기 애플리케이션이 종료되는 신호에 따라, 커널(kernel)의 시그널 핸들러(signal handler)를 상기 크래쉬가 발생한 시점의 메모리 정보 및 상기 크래쉬의 발생 이전까지의 메모리 결함 정보를 모니터링하는 시그널 핸들러로 교체하는, 컴퓨터 시스템.
  13. 제12 항에 있어서,
    상기 크래쉬 모니터링 모듈은 상기 교체된 시그널 핸들러를 호출하고, 상기 호출된 시그널 핸들러를 이용하여 상기 크래쉬와 관련된 애플리케이션의 콜 스택(Call Stack) 정보를 수집하는, 컴퓨터 시스템.
  14. 제13 항에 있어서,
    상기 결함 분석 모듈은 상기 결함 탐지 모듈에서 탐지한 상기 메모리의 글로벌 영역, 스택 영역, Heap 영역에서의 메모리 결함 정보 및 상기 크래쉬 모니터링 모듈에서 수집한 상기 콜 스택 정보에 기초하여 상기 메모리 오류의 원인을 분석하는, 컴퓨터 시스템.
  15. 컴퓨터로 읽을 수 있는 저장 매체를 포함하는 컴퓨터 프로그램 제품에 있어서,
    상기 저장 매체는,
    애플리케이션의 실행 이전에 상기 애플리케이션의 글로벌 변수(Global variable) 및 로컬 변수(local variable) 정보를 추출하는 단계;
    추출된 상기 글로벌 변수 및 상기 로컬 변수 정보를 인포메이션 태그 저장부(information tag repository)에 저장하는 단계; 및
    상기 인포메이션 태그 저장부에 저장된 상기 글로벌 변수 및 상기 로컬 변수 정보와 상기 애플리케이션이 실행 중에 수집된 동적 메모리(dynamic memory) 정보에 기초하여 메모리 오류를 검출하는 단계;
    를 수행하는 명령어들(instructions)을 포함하는, 컴퓨터 프로그램 제품.
PCT/KR2019/006330 2018-05-28 2019-05-27 메모리 오류를 검출하는 방법 및 시스템 WO2019231194A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020180060689A KR102545765B1 (ko) 2018-05-28 2018-05-28 메모리 오류를 검출하는 방법 및 시스템
KR10-2018-0060689 2018-05-28

Publications (1)

Publication Number Publication Date
WO2019231194A1 true WO2019231194A1 (ko) 2019-12-05

Family

ID=68698837

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/006330 WO2019231194A1 (ko) 2018-05-28 2019-05-27 메모리 오류를 검출하는 방법 및 시스템

Country Status (2)

Country Link
KR (1) KR102545765B1 (ko)
WO (1) WO2019231194A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111382077A (zh) * 2020-03-13 2020-07-07 北京奇艺世纪科技有限公司 应用程序崩溃原因定位方法、装置、电子设备及存储介质
CN113672237A (zh) * 2021-09-03 2021-11-19 支付宝(杭州)信息技术有限公司 防内存越界的程序编译方法及装置

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274060B (zh) * 2020-02-10 2023-07-28 广州虎牙科技有限公司 一种确定内存异常的方法、装置、设备和存储介质
KR102254159B1 (ko) * 2020-12-09 2021-05-18 연세대학교 산학협력단 운영체제 커널 메모리의 실시간 오류 검출 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080096963A (ko) * 2007-04-30 2008-11-04 슈어소프트테크주식회사 메모리 오류 검출 방법
US20090249289A1 (en) * 2008-03-28 2009-10-01 Microsoft Corporation Detecting memory errors using write integrity testing
KR20120082798A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 컴퓨터 시스템에서 메모리 접근의 에러를 검출 장치 및 방법
KR20140000397A (ko) * 2012-06-22 2014-01-03 인텔렉추얼디스커버리 주식회사 다중 언어로 개발된 어플리케이션을 위한 프로파일링 수행 시스템 및 이를 이용한 프로파일링 방법
US20150261596A1 (en) * 2014-03-17 2015-09-17 Microsoft Corporation Framework for user-mode crash reporting

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080096963A (ko) * 2007-04-30 2008-11-04 슈어소프트테크주식회사 메모리 오류 검출 방법
US20090249289A1 (en) * 2008-03-28 2009-10-01 Microsoft Corporation Detecting memory errors using write integrity testing
KR20120082798A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 컴퓨터 시스템에서 메모리 접근의 에러를 검출 장치 및 방법
KR20140000397A (ko) * 2012-06-22 2014-01-03 인텔렉추얼디스커버리 주식회사 다중 언어로 개발된 어플리케이션을 위한 프로파일링 수행 시스템 및 이를 이용한 프로파일링 방법
US20150261596A1 (en) * 2014-03-17 2015-09-17 Microsoft Corporation Framework for user-mode crash reporting

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111382077A (zh) * 2020-03-13 2020-07-07 北京奇艺世纪科技有限公司 应用程序崩溃原因定位方法、装置、电子设备及存储介质
CN111382077B (zh) * 2020-03-13 2023-09-01 北京奇艺世纪科技有限公司 应用程序崩溃原因定位方法、装置、电子设备及存储介质
CN113672237A (zh) * 2021-09-03 2021-11-19 支付宝(杭州)信息技术有限公司 防内存越界的程序编译方法及装置
CN113672237B (zh) * 2021-09-03 2022-03-11 支付宝(杭州)信息技术有限公司 防内存越界的程序编译方法及装置

Also Published As

Publication number Publication date
KR102545765B1 (ko) 2023-06-21
KR20190135337A (ko) 2019-12-06

Similar Documents

Publication Publication Date Title
WO2019231194A1 (ko) 메모리 오류를 검출하는 방법 및 시스템
WO2020253034A1 (zh) 客户端埋点测试方法、装置、设备及存储介质
CN102736978B (zh) 一种检测应用程序的安装状态的方法及装置
CN107515808B (zh) 日志记录方法、装置、计算机设备和计算机可读存储介质
WO2011105860A2 (en) Method and apparatus for generating minimum boot image
US11182479B2 (en) Call stack acquisition device, call stack acquisition method, and call stack acquisition program
WO2021118125A1 (ko) 안드로이드 어플리케이션에 의해 실행 가능한 보안 컨테이너 구축 장치, 방법 및 그 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
WO2019134223A1 (zh) 一种日志生成方法、装置、计算机设备及存储介质
WO2020218870A1 (en) Electronic apparatus and method for controlling thereof
CH716656A2 (it) Sistema e metodo di generazione e archivazione di metadati specifici dell'informatica forense.
WO2022124720A1 (ko) 운영체제 커널 메모리의 실시간 오류 검출 방법
WO2016064024A1 (ko) 이상 접속 검출 장치 및 방법
WO2018236141A1 (ko) 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
CN111274130A (zh) 一种自动化测试方法、装置、设备及存储介质
WO2014185627A1 (ko) 데이터 프로세싱 시스템 보안 장치와 보안방법
WO2022071615A1 (ko) 장애 예측 방법, 그리고 이를 구현하기 위한 장치
CN112068932A (zh) 应用程序的集成、监控方法、装置、系统、设备及介质
WO2023229066A1 (ko) 리버싱 엔진 기반의 문서 행위를 판단하기 위한 방법 및 이를 위한 장치
CN108959070B (zh) 一种基于代码对象的Python钩子函数方法和装置
WO2016190485A1 (ko) 데이터 무단 엑세스 차단 방법 및 그 기능이 구비된 컴퓨팅 장치
US11726860B2 (en) Intelligent automatic support
WO2016108677A1 (ko) 웹 컨텐츠 출력 장치 및 방법
CN114490266A (zh) 一种数据采集方法、装置、设备及存储介质
WO2024063171A1 (ko) 자식 프로세스의 악성 행위를 검사하기 위한 방법 및 이를 위한 장치
WO2020022616A1 (ko) 전자 장치 및 그의 동작 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19812108

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19812108

Country of ref document: EP

Kind code of ref document: A1