WO2018236141A1 - 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램 - Google Patents

크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램 Download PDF

Info

Publication number
WO2018236141A1
WO2018236141A1 PCT/KR2018/006955 KR2018006955W WO2018236141A1 WO 2018236141 A1 WO2018236141 A1 WO 2018236141A1 KR 2018006955 W KR2018006955 W KR 2018006955W WO 2018236141 A1 WO2018236141 A1 WO 2018236141A1
Authority
WO
WIPO (PCT)
Prior art keywords
crash
stack trace
lines
line
report
Prior art date
Application number
PCT/KR2018/006955
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 WO2018236141A1 publication Critical patent/WO2018236141A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • 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/079—Root cause analysis, i.e. error or fault diagnosis

Definitions

  • the present invention relates to crash report grouping, and more particularly to analyzing a crash log of a mobile app to perform crash report grouping.
  • App-crash management is essential because the quality control and maintenance of applications (called "apps") is directly linked to revenue.
  • apps applications
  • To reduce the application crash rate you have to analyze many crash logs, identify the cause of the crash, and troubleshoot.
  • the app manager needs to identify the cause of the crash and, in order to troubleshoot it, provide the cause of the numerous crash logs, and sort and manage it efficiently. This requires crash grouping.
  • crash report grouping tools such as Crashlytics, Apteligent, and Hockey App, but they do not recognize system libraries, classes or methods that depend on the OS version or device, or the game development engine stack trace lines, Since the grouping is performed through the matching check of the stack trace, the degree of grouping is low, which is inefficient. That is, several grouping tools have grouped the crashes regardless of whether they are related to systems, development engines, or game apps.
  • a crash report grouping method suitable for a crash report of a mobile application is presented.
  • the present invention extracts user logic lines of the crash stack trace and performs crash grouping.
  • the root cause of the crash is preferentially grouped, ignoring the game engine or the system library. Compare similarities by considering variable lines of stack trace, but exclude methods that vary from runtime to runtime.
  • a crash report grouping method performed by a server, comprising: receiving a crash report for an application installed in the terminal from a terminal capable of communicating with the server; In the received crash report, the platform, language layer, or application development engine type in which the crash occurred Identifying a crash location that identifies the crash as a reference; Confirming an exception type of the crash described in the received crash report; Removing lines associated with the system and lines associated with the application development engine from the stack trace of the crash report, wherein if there were only lines associated with the system in the stack trace prior to removal, Or all of the lines associated with the application development engine, if there are only lines associated with the application development engine in the stack trace before the removal, or if there are only lines related to the system-related lines and the application development engine, Leaving the stack trace line; Removing the lines in the stack trace and extracting the remaining refined stack traces; and comparing the result of the comparison of the crash location, the exception type, the root cause line being the top line
  • Another embodiment of the present invention provides a computer program stored in a computer readable recording medium embodying the above crash report grouping method.
  • One embodiment of the present invention is a crash report grouping server, comprising: a crash report receiving unit for receiving a crash report for an application installed in the terminal from a terminal capable of communicating with the server; In the received crash report, the platform, language layer, or application development engine type in which the crash occurred A crash location confirmation unit for confirming a crash location for distinguishing a crash based on the crash location; A crash exception type checking unit for checking an exception type of the crash described in the received crash report; A stack trace line removal that removes lines associated with the system and lines associated with the application development engine from a stack trace of the crash report, wherein if there were only lines associated with the system in the stack trace prior to removal, Leaving only some or all of the lines associated with the system and having only the lines associated with the application development engine in the stack trace prior to removal or only lines related to the system related lines and the application development engine, The stack trace line remover leaving some or all of the associated lines; A refined stack trace extractor for removing the lines from the stack trace and extracting the remaining refined stack traces; And
  • the present invention provides a grouping method that is effective for grouping crash logs of mobile apps, particularly crash grouping specific to mobile game applications.
  • a report including a device model name, an OS version, and a game app version is recognized as the same crash as a report of another crash, shooting can be applied.
  • FIG. 1 is a schematic block diagram of a system for performing crash report grouping according to the present invention.
  • FIG 2 is an internal configuration diagram of an example of the crash report grouping server 40 according to the present invention.
  • 3A and 3B are flowcharts illustrating a process of a crash report grouping server according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating a detailed process of the second crash report grouping (S320) in operation of the crash report grouping server according to FIG. 3B.
  • FIG. 5 is a schematic diagram for explaining the primary and secondary crash report grouping and the typical crash report DB 207 structure.
  • - Crash means that the computer or the program itself is stopped during execution.
  • - Crash Report is a report in which a crash report application or module catches all the information about a crash that occurred in a user terminal and is an example of a crash log file.
  • the crash log file may contain various information about the crash, such as the header, stack trace, location of the crash, CPU usage, or crash capture picture.
  • POSIX signal types are process signals used by Unix-like, POSIX-compliant operating systems to report exceptional situations of processes in the operating system. Depending on the type of signal, the process that receives the signal ignores it, or it can not proceed, or stops the program.
  • POSIX signals include SIGABRT (process abort signal), SIGBUS (access to a portion of an undefined memory object), SIGFPE (an arithmetic operation with errors), SIGILL (invalid command), SIGSEGV have.
  • exceptions include NullReferenceException (no object address), IndexOutOfBoundException (the index specified in the object array can not be referenced), and IllegalStateException (object state not suitable for method invocation).
  • - Crash location refers to the type of platform, language layer or application development engine on which the actual crash occurred. It can be divided into iOS / Android (operating system), Java / C # (virtual machine language), Native (hardware friendly low level language, operating system implemented language) and game engine type (Unity, Unreal, cocos2d etc.). For example, Android Unity Native Crash, iOS Native Crash, Java Exception, Android C # Script Exception, and Android Native Crash.
  • Java Exception and Android C # Script Exception are strictly classified as an application exception or a crash in the present invention.
  • the class and method name are detailed in the stack trace.
  • Android Unity Native Crash is an exceptional case, in which NDK catches crashes directly from the Unity stage before catching the crash, and creates a stack trace, which does not require a separate mapping process.
  • Android and iOS Native Crash will fall into a memory address dump file when a crash occurs, so you can use a stack trace with memory addresses before you can map it to an easily identifiable class. If memory addresses are mapped to easily identifiable classes and method names, meaningful method lines can be distinguished and grouped.
  • a method is a function that performs some logic.
  • - Stacktrace is a list of methods, classes, and library calls before and when an error occurred. It consists of a plurality of lines.
  • - Crash group type is a crash type that distinguishes the highest level of code implementation among the lines that are easy to troubleshoot as shown in the crash stack trace.
  • the ranking of crash group types is higher in the following order: application crash group, development engine crash group, and system crash group.
  • - Grouping means to classify or bundle the same kind.
  • System libraries, classes, or methods include Device, OS, OS-SDK related libraries, classes or methods, and system libraries are also referred to as system frameworks.
  • Root Cause is the root cause of an event.
  • - Symbolication is a task to convert stack trace into a human-readable format by mapping addresses displayed in hexadecimal to function names using symbol files.
  • - NDK (Native Development Kit) is a development tool that supports C / C ++ native development so that you can program Android basic interface directly besides Android's Android Software Development Kit (SDK).
  • Game Engine is a software-based tool (framework) that provides various functions for game development, also called game development engine.
  • - Unity is a Unity game engine that provides a variety of platforms.
  • the user terminal 10 refers to a terminal possessed by an application user.
  • the network may be a wired or wireless network.
  • the application 101 is a game application
  • the application server 30 is a game server
  • the user terminal 10 may be a mobile terminal.
  • any type of device can be used as long as it is a device capable of installing and executing a mobile device or a game application such as a smart phone or a tablet PC.
  • the user terminal 10 installs a game application, connects to the game server 30, and proceeds with the game.
  • the game application 101 installed in the user terminal 10 may have a crash reporting module 102 built therein.
  • the crash reporting module 102 performs a function of catching a crash generated in an application, generating a crash log file, and transmitting the generated crash log file to the crash report grouping server 20.
  • the game server 30 can be constructed and operated by a game developer, or a company that provides a plurality of games or a publishing company can receive and manage the game server from the game developer directly.
  • the crash report grouping server 20 receives a crash report (e.g., a crash log file) generated at the time of game progress in the user terminal 10, analyzes the crash type, and performs grouping.
  • the crash report grouping server 20 can be located in a game developer or a publishing company in a configuration different from the game server 30. Alternatively, unlike FIG. 1, the crash report grouping server 20 may be configured as a part in the application server 30.
  • FIG. 1 the crash report grouping server 20 may be configured as a part in the application server 30.
  • the grouped crash report will be sent to the game developer for trouble shooting, and then the game application will be updated and downloaded to the user terminal (not shown).
  • the crash report receiving unit 201 receives the crash log file from the user terminal 10 and transfers the received crash log file to each constituent part of the crash report grouping server 40.
  • the crash location confirmation unit 202 receives the crash log file and refers to the crash location DB 212 as location information in which a crash occurred, recorded in a separate field from the header of the log file field or the field in which the stack trace exists, And sends it to the crash report matching unit 206.
  • the location of the crash may be indicated by platform, language layer or game engine type or a combination thereof.
  • the platform is an iOS or an Android operating system
  • the language layer is a Java or C # virtual machine (VM) language layer, or a C or C ++ native language layer
  • the game application development engine type is Unity, Unreal or cocos2d.
  • the crash location is Java Exception for Android crashes, Android Unity Native Crash, Android Native Crash, and C # Script Exception, and iOS Crash can be one of iOS Native Crash and C # Script Exception.
  • the crash exception type checking unit 203 refers to the crash exception type DB 213 and checks the header of the crash log file or the crash exception type described in the stack trace and outputs the information to the crash report matching unit 206. [ Lt; / RTI >
  • the stack trace line removing unit and the refined stack trace extracting unit 204 maintain only the lines useful for distinguishing the crash reports from each other, Line is removed to extract the purified stack trace and sent to the crash report matching unit 206 and / or the crash group type classification unit 205.
  • the line removal is to remove lines containing the system library, class or method name, and then the lines containing the application development engine library, class or method name, by line of the stack trace, Confirms the name or method name, and proceeds to remove the line with reference to the stack trace line DB (214).
  • the stack trace line DB 214 stores data of library names, class names, and method names associated with the system lines, the application development engine lines, and the application lines, respectively.
  • the lines related to the system and the lines related to the application development engine are removed and the lines related to the application are left. If there are only lines related to the system in the stack trace before the removal Leaves some or all of the lines associated with the system and if there are only lines associated with the application development engine in the stack trace prior to removal or only lines related to the system related lines and the application development engine, Leaving some or all of the lines associated with the engine.
  • a line containing the removed system library, class or method name Some of or all of them are recovered and extracted with purified stack traces. If only some of the lines are recovered, some of the recovered stack trace lines are useful lines to distinguish the crash reports from each other, and the unrecovered or removed stack trace lines may contain lines common to crash reports or part of the stack trace line Are lines that are not useful for classifying crash reports, such as missing lines, or lines containing methods that vary from runtime to runtime.
  • the stack trace may be distinguished from the header, but if the stack trace includes a header, the removal function may include removing the header from the stack trace as well.
  • the following refined stack trace extraction without the stack trace line removal may be possible. That is, if there are lines associated with the application in the stack trace lines, some or all of them are first extracted to make a refined stack trace. If there are no lines associated with the application, it is checked whether there are lines associated with the application development engine and if any, some or all of them are extracted as refined stack traces. In the absence of a line associated with the application and application development engine, the remaining lines, i.e., some or all of the lines associated with the system, may be extracted as refined stack traces.
  • the crash group type classification unit 205 receives the stack trace lines from the stack trace line removal and refined stack trace extraction unit 204 and then writes the relevant crash group types to the application crash group, Group, and system crash group, and sends the information to the crash report matching unit 206.
  • the crash group type classifying unit 205 may receive the crash log file from the crash report receiving unit 201 and classify the highest code implementation level among the lines that are easy to trouble shoot.
  • the crash group type is ranked in the order of an application crash group, a development engine crash group, and a system crash group, and the crash group type checks each related crash group
  • the top-level crash group among related crash groups can be classified as a crash group type of the corresponding log file.
  • the classification of the crash group type performed by the crash group type classification unit 205 may be performed together in the stack trace line removal unit and the purified stack trace extraction unit 204.
  • the stack trace hashing unit 208 may use the hash algorithm and the stack trace hashing DB (i. E., If the crash location is Native Crash in AOS or iOS, 209) to generate a hash key, which is a fixed length key value corresponding to the stack trace lines including the memory address value.
  • the symbolization unit 210 refers to the symbolization DB 211 and maps to the class name and / or method name corresponding to the memory address value of the stack trace lines. If the symbolization fails, the stack trace line removing unit and the refined stack trace extracting unit 204 can not perform the function, and the hash value generated by the stack trace hashing unit 208 is output from the crash report matching unit 206 Can be utilized.
  • the stack trace hashing unit 208 and the symbolizing unit 210 can perform hashing and symbols, No, there is no need.
  • the crash report matching unit 206 compares the crash location received from the crash location confirmation unit 202, the exception type received from the crash exception confirmation unit 203, the extracted and extracted type information received from the refined stack trace extraction unit 204, The stack trace, and the root causal line, which is the top line of the refined stack trace, are compared with the crash position, exception type, refined stack trace, and root causal line of the representative crash reports for each cause stored in the representative crash report DB 207 Confirm the representative crash report. And the app code identifying the corresponding game application can also be used for matching (not shown).
  • the crash group type received from the crash group type classifying unit 205 can be used to compare with and compare with the crash group type of the representative crash report.
  • an application crash group type it can be determined that the extracted purified stack trace and the refined stack trace of the representative crash report are matched when they are equal to each other.
  • a development engine class group type or a system crash group type it can be determined that the extracted purified stack trace and the refined stack trace of the representative crash report are matched when they are similar to each other.
  • the similarity between the extracted refined stack trace and the refined stack trace of the representative crash report indicates that the root probability lines are equal to each other and the ratio of the number of lines of mutually matching stack traces is equal to or greater than a certain percentage, %, It can be judged to be similar and match.
  • the crash report matching unit 206 refers to the representative crash report DB to represent the crash location, the exception type, and the hash value of the stack trace, It is possible to compare the crash location of the crash reports with the hash value of the exception type and the stack trace to determine whether they are matched.
  • the crash report matching unit 206 determines whether or not matching is performed based on a crash position, an exception type, and an app code, performs a primary crash report grouping, and then performs matching on the basis of a crash group type, a root causeline, The second crash report grouping can be performed.
  • the representative crash report DB 207 is configured for each app code, and the representative crash reports having the same exception type and crash position among a plurality of representative crash reports are classified into one primary group A plurality of primary groups may be included.
  • representative crash reports (or these same items related to stack traces, which may be referred to as representative stack traces) may be named as representative crash reports with the same crash group type, root causeline, refined stack trace, or stack trace hash value ) May be classified into one secondary group. Accordingly, matching through the above-described primary and secondary crash report grouping can be effectively performed.
  • Table 1 summarizes the format of the representative crash report described above.
  • the information in the left column in Table 1 below is used for primary crash report grouping and the information in the right column can be used for secondary crash report grouping.
  • the number of lines is an attribute for improving the grouping speed, and is not an essential feature in comparison for grouping.
  • App code - code by game application Group Type (one of the following types) - Game Crash - Engine Crash - System Crash Crash location ( one example of crash location below) - Android Java Exception - Android Unity Native Crash - Android Native Crash - Android C # Script Exception - iOS Native Crash - iOS C # Script Exception Lines can-stack trace line number Root Cause Line - Crash Cause Line Exception type (one of the following types of exception types) - POSIX signal - Exception name Stack trace (one of the data below) - Refined stack trace - stack trace hash value
  • 3A and 3B are flowcharts illustrating a process of a crash report grouping server according to an embodiment of the present invention.
  • the crash report receiving unit 201 After receiving the crash report (S300), the crash report receiving unit 201 identifies the crash location, the exception type, and the application code (S 302 and 202 and 203 in FIG. 2), and based on this information, the crash report matching unit 206 , The primary crash report grouping is performed (S304).
  • the crash exception type is Android Native Crash or iOS Native Crash (S306). If the exception type is confirmed as another exception type, the system related lines are checked by line by line in the stack trace (S308). After the step S308, it is checked whether the stack trace line remains (S310).
  • the application development engine related line is removed from the stack trace (S312). If it is confirmed that there is no remaining stack trace line in the step S310, A part of the system related stack trace line is recovered (S322). (S 314) whether a stack trace line remains after the stack trace line removal through step S 312 (S 314), and restores a part of the removed application development engine related line if not left (S 324).
  • the determination criteria for some of the lines recovered in steps S322 and S324 and some of the lines that are not recovered and recovered are as described above in connection with the stack trace line removal and refined stack trace extraction unit 204. [ Depending on the implementation, the entire line may be recovered without selectively recovering in steps S322 and S324.
  • the remaining stack trace lines i.e., application related stack trace lines, via step 314, or system related lines or development engine related lines recovered through step 322 and step 324, are extracted as refined stack traces,
  • the top line that is, the leading line is extracted as the root causal line (S316). Since the extracted refined stack trace is related to any one of the system, the application development engine, and the application, the crash group type is classified based on the relevance thereof (S318). Based on the extracted refined stack trace, the root cause line, and the crash group type, the crash report subgroup (secondary group) matching among the plurality of subgroups in the first-classified crash report group is confirmed (S320).
  • the stack trace is subjected to hashing (S326) and symbolization (S328, S330) to remove the system related line (S308). Steps S326 and S328 may be performed even if the order is changed. If symbolization is not possible in step S328, the second-stage crash report grouping (S320) may be performed using the stack trace hash value generated in step S326.
  • FIG. 4 is a flowchart illustrating a detailed process of the second crash report grouping (S320) in operation of the crash report grouping server according to FIG. 3B.
  • the stack trace line is defined as a hash value (S400). Otherwise, whether or not the extracted refined stack trace is an application crash group type is confirmed (S402).
  • the extracted refined stack traces are compared to the refined stack traces (" representative stack traces ") of a plurality of representative crash reports in the pre-classified same primary crash report group stored in the representative crash report DB 207 Quot;) and judges whether there is the same stack trace (S404).
  • the extracted representative stack trace is compared with the corresponding representative stack trace (S406). If there is no identical representative stack trace, the extracted representative stack trace is compared with the representative representative stack trace. Is added to the crash report group (S412).
  • the extracted refined stack trace is compared with a plurality of representative stack traces in the same pre-classified primary group stored in the representative crash report DB 207, (S408), it is confirmed that the number of mutually matching stack trace lines is, for example, 70% or more (S410), and the representative stack trace satisfying the two conditions is matched (S406). If at least one of the above two conditions is not satisfied, the extracted refined stack trace is added to the same primary group in the representative crash report DB 207 (S412).
  • the hash value of the received stack trace is compared with the hash value of a plurality of representative stack traces in the same pre-classified primary group, respectively, (S414). If there is no existing representative stack trace having the same hash value, the existing representative stack trace is matched with the representative crush report having the same hash value (S406). If there is no existing representative stack trace having the same hash value, Group (S412).
  • the app code is 'mherosgb' displayed on line 3, which can be checked by referring to the app code checking unit and the app code DB, which are omitted from the figure.
  • the field in the crash log file with the crash location is not shown in the sample above, but it is assumed that raw data has been identified as "Crash location: Android Unity Native Crash". Since the crashed location includes a separate field title called Crash location, it is easy to check and can be consulted with reference to the DB 212. It can exist in a separate field from the stack trace / header, ≪ / RTI > 2 for the convenience of description will be described only to the minimum necessary for the description in this sample description, and the order of description will be described in accordance with the flow charts of Figs.
  • the crash exception type checking unit 203 can check SIGSEGV, which is one of POSIX signal types among the crash exception types recorded in the crash exception type DB 213, on line 1.
  • SIGSEGV is an exception type that means an invalid memory reference. With this information, primary crash report grouping is possible.
  • the stack trace line removal unit and the refined stack trace extraction unit 204 sequentially descend from the line 8 and remove the line related to the system by referring to the stack trace line DB 214 .
  • Line 8 is removed as libc is the system library name, kill is the system related method, and 12 is the system-specific stack trace line.
  • System related lines from line 9 to line 38 are not found.
  • a number of stack trace lines (lines 9 to 38) remain after the removal of system related lines, and then the application development engine related lines are removed.
  • Line 9 means that libmono is the name of the game development engine library, 002ad36c is the address of the method, and Native Method is the method implemented in the native language.
  • Lines 10 to 16, and lines 21 to 38 are sequentially removed while referring to the stack trace line DB 209 for the same or similar reason.
  • Stack trace lines 17-20 remain after the game development engine line is removed. These lines are application related lines. These lines can be extracted into the refined stack trace and the top line 17 can be the root causal line. However, for more effective grouping, it is possible to set the stack trace line removing unit 204 and the refined stack trace extracting unit 204 so as to further delete the lines having no location information among the remaining application related lines.
  • the extracted refined stack trace is compared with the representative stack traces of the various subgroups in the primary grouped group in the representative crash report DB 207 By comparison, the same representative stack trace is searched and matched. If they do not match, a new subgroup is created in the primary group in the representative crash report DB 207 and stored as a new representative stack trace.
  • the extracted refined crash report will be used to look at the root cause line and stack trace, and to deduce clues for troubleshooting.
  • the game logic implemented by the game developer GetSummoner method, which obtains an object called Summoner, executes the logic that refers to the wrong memory, resulting in a crash.
  • the game engine related stack trace line can be distinguished by the class name or method name of the game engine, since there is no game engine library name and only the game library name exists.
  • the library name of each stack trace line in sample 2 above is Full2016. This library name is used in common between game library and game engine library.
  • Subsequent class eg EventDelegate
  • method eg Execute_m213950963
  • All of the stack trace lines of Sample 2 can be understood as game engine related lines. This determination is made possible based on information such as the name of the iOS game library stored in the stack trace line DB 214.
  • the app code is 'full2016' indicated in the identifier field, and can be confirmed by referring to the app code identifying unit and the app code DB, which are omitted from the figure.
  • the stack trace hash value obtained by referring to the stack trace hashing DB 209 is as follows. If the symbolization is not successful, this hash value will be used to verify matching with the representative stack trace.
  • the stack trace hash value is a fixed length data value created by a hash algorithm.
  • the hash values below are values created by using the MD5 algorithm, which is one of the hashing algorithms, on lines 0 to 12 of the above log file.
  • the stack trace successfully symbolized with reference to the symbolization DB 211 is as follows.
  • Stack trace line DB 214 may include information about lines according to each crash group type, information about general lines that are checked in most stack traces, information about methods that vary from runtime to runtime, and so on. Referring to the stack trace line DB (214), it is checked whether or not the system related line is sequentially from the 0th line to the 12th line. As a result, all of the lines 0 to 12 are deleted because all of them are system-related lines. After this deletion, there are no remaining lines, so these system related lines must be restored. When recovering, lines 0, 1, and 12 refer to the stack trace line DB 214 and can recover only lines 2 to 11 without recovering because they are included in most stack traces.
  • These lines 2 to 11 are extracted into the purified stack trace, and the line 2, which is the uppermost line, is extracted as the root causal line. Since the crash group type is classified into the system type, the second crash report grouping is performed based on the information. Among the representative stack traces of the subgroups in the primary sorted group, the representative stack trace having the same crash group type and the extracted root causeline and having at least seven of the lines 2 to 11, that is, 70% or more of the same stack trace is searched. If there is a matching representative stack trace through the search, the extracted refined stack trace extracted in the corresponding subgroup is stored in the DB 207. If there is no matching representative stack trace, the representative stack trace of the new subgroup And stores it in the DB 207 as a trace.
  • the primary grouping is classified as a crash exception type only for the sake of explanation.
  • the primary group is divided into groups such as NullReferenceException, IndexOutBoundException, and IllgalStateException, and each primary group includes a plurality of subgroups.
  • the IndexOutBoundException group contains subgroups D, E, and F, and each subgroup contains representative stack traces.
  • the information Upon receipt of a new crash log file to be grouped, the information is classified into any of the above primary groups with information such as a crash location, an exception type, and an application code, and then classified into information of the extracted refined stack trace and a crash group type Proceed to the second classification.
  • Crash report grouping and Apteligent grouping results according to an embodiment of the present invention are compared.
  • the mobile game app used Naver Raven, and the number of log files used by each type of crash was 80 for Java Exception log, 200 for NDK Native crash log, 200 for iOS Native crash log, totaling 480 log files. .
  • As a result of crash report grouping Apteligent is classified into 406 crash groups, whereas the grouping method according to the embodiment of the present invention is classified into 282 crash groups. That is, the number of groups was reduced by about 30% as compared with that of Apteligent.
  • the above exemplary methods according to the present invention may be implemented in a computer program product, a computer program product recorded on a recording medium readable by a computer (including all devices having an information processing function) May be implemented in a variety of ways including, but not limited to, applications, logic circuits, custom semiconductors, or firmware.
  • Examples of the computer-readable recording medium include, but are not limited to, ROM, RAM, CD, DVD, magnetic tape, hard disk, floppy disk, hard disk and optical data storage.
  • the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner.

Abstract

서버에서 수행되는 크래시 리포트 그룹핑 방법을 제공한다. 그룹핑은 서버와 통신가능한 단말기로부터 단말기에 설치된 애플리케이션에 대한 크래시 리포트를 수신하고; 수신된 크래시 리포트에서 크래시가 발생한 플랫폼, 언어 계층 또는 애플리케이션 개발엔진 종류를 기준으로 크래시를 구분하는 크래시 위치(crash location)를 확인하고; 수신된 크래시 리포트에 기재된 크래시의 예외 타입(exception type)을 확인하고; 크래시 리포트의 스택 트레이스(stack trace)에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하고; 스택 트레이스에서 라인들을 제거하고 남은 정제된 스택 트레이스를 추출하고; 크래시 위치, 예외 타입, 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인(root cause line), 및 추출된 정제된 스택 트레이스를 크래시 원인별 대표 크래시 리포트의 크래시 위치, 예외 타입, 루트 코즈 라인, 및 정제된 스택 트레이스와 비교하여 매칭여부를 판단한다.

Description

크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
본 발명은 크래시 리포트 그룹핑에 관한 것으로, 더욱 구체적으로는 모바일 앱의 크래시 로그를 분석하여 크래시 리포트 그룹핑을 수행하는 것에 관한 것이다.
애플리케이션('앱'이라고 불리움)의 품질관리 및 유지보수는 매출과 직결되므로 앱 크래시 관리는 필수적이다. 애플리케이션 크래시 비율을 떨어뜨리기 위하여 수많은 크래시 로그들을 분석하고 발생 원인을 파악하여 트러블 슈팅을 해야한다. 앱 관리자가 크래시 원인을 파악하고, 나아가 트러블 슈팅을 위해서는 수많은 크래시 로그의 원인을 제공받고 분류 및 관리가 효율적으로 이루어져야 한다. 이를 위하여 크래시 그룹핑을 필요로 한다.
종래에는 동일한 원인에 따른 크래시임에도 불구하고, 리포트에 디바이스 모델명, OS 버젼, 게임앱 버젼이 포함되므로, 서로 다른 크래시로 보일 수 있으므로, 트러블 슈팅에 어려움이 있었다. Crashlytics, Apteligent, Hockey App 등의 크래시 리포트 그룹핑 툴이 있으나, 이들은 OS 버젼이나 기기마다 달라지는 시스템 라이브러리, 클래스 또는 메쏘드, 또는 게임 개발 엔진관련 스택 트레이스 라인을 인지하지 않고 이들을 제거하지 않은 상태에서 크래시 리포트의 스택 트레이스의 일치 검사를 통하여 그룹핑하므로, 그룹핑의 정도가 낮아 비효율적이다. 즉, 여러 그룹핑 툴은 크래시가 시스템, 개발엔진, 또는 게임앱에 관한 것인지 구별하지 않고 그룹핑을 해왔다.
서버나 윈도우 크래시는 그룹핑 판단이 간단하였으나, 모바일 환경에서는 크래시 그룹핑이 다양한 모바일 기기 및 OS의 종류 등의 이유로 그룹핑이 쉽지 않은 문제점이 있다. 그룹핑이 어려우면 크래시 리포트별로 트러블 슈팅을 새롭게 또는 다르게 적용하여야 하므로 신속하고 효율적인 트러블 슈팅이 어려웠다.
본 발명의 일실시예에 따르면, 모바일 앱의 크래시 리포트에 적합한 크래시 리포트 그룹핑 방법을 제시한다.
이를 위해 본 발명은 크래시 스택 트레이스의 사용자 로직 라인을 추출하여 크래시 그룹핑을 행한다. 본 발명의 일 실시예에서는 게임 엔진이나 시스템 라이브러리를 무시하고, 크래시의 루트 코즈(root cause)를 우선적으로 그룹핑한다. 스택 트레이스의 가변적인 라인을 고려하여 유사성을 비교하되, 런타임마다 달라지는 메소드(method)는 제외한다.
본 발명의 일실시예는 서버에서 수행되는 크래시 리포트 그룹핑 방법으로서, 상기 서버와 통신가능한 단말기로부터 상기 단말기에 설치된 애플리케이션에 대한 크래시 리포트를 수신하는 단계; 상기 수신된 크래시 리포트에서 상기 크래시가 발생한 플랫폼, 언어 계층 또는 애플리케이션 개발엔진 종류를 기준으로 크래시를 구분하는 크래시 위치(crash location)를 확인하는 단계; 상기 수신된 크래시 리포트에 기재된 크래시의 예외 타입(exception type)을 확인하는 단계; 상기 크래시 리포트의 스택 트레이스(stack trace)에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하되, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남기는, 상기 스택 트레이스 라인 제거 단계; 상기 스택 트레이스에서 상기 라인들을 제거하고 남은 정제된 스택 트레이스를 추출하는 단계, 및 상기 크래시 위치, 상기 예외 타입, 상기 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인(root cause line), 및 상기 추출된 정제된 스택 트레이스를 크래시 원인별 대표 크래시 리포트의 크래시 위치, 예외 타입, 루트 코즈 라인, 및 정제된 스택 트레이스와 비교하여 매칭여부를 판단하는 단계를 포함하는 크래시 리포트 그룹핑 방법을 제공한다.
본 발명의 또 다른 일실시예는 위 크래시 리포트 그룹핑 방법을 구현하는 컴퓨터 판독가능한 기록매체에 저장된 컴퓨터 프로그램을 제공한다.
본 발명의 일실시예는 크래시 리포트 그룹핑 서버로서, 상기 서버와 통신가능한 단말기로부터 상기 단말기에 설치된 애플리케이션에 대한 크래시 리포트를 수신하는 크래시 리포트 수신부; 상기 수신된 크래시 리포트에서 상기 크래시가 발생한 플랫폼, 언어 계층 또는 애플리케이션 개발엔진 종류를 기준으로 크래시를 구분하는 크래시 위치(crash location)를 확인하는 크래시 위치 확인부; 상기 수신된 크래시 리포트에 기재된 크래시의 예외 타입(exception type)을 확인하는 크래시 예외타입 확인부; 상기 크래시 리포트의 스택 트레이스(stack trace)에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하는 스택 트레이스 라인 제거부로서, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남기는, 상기 스택 트레이스 라인 제거부; 상기 스택 트레이스에서 상기 라인들을 제거하고 남은 정제된 스택 트레이스를 추출하는 정제된 스택 트레이스 추출부; 및 상기 크래시 위치, 상기 예외 타입, 상기 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인(root cause line), 및 상기 추출된 정제된 스택 트레이스를 크래시 원인별 대표 크래시 리포트의 크래시 위치, 예외 타입, 루트 코즈 라인, 및 정제된 스택 트레이스와 비교하여 매칭여부를 판단하는 크래시 리포트 매칭부를 포함하는 크래시 리포트 그룹핑 서버를 제공한다.
본 발명은 모바일 앱의 크래시 로그를 그룹핑하는데 효과적인 그룹핑 방법을 제공하며, 특히 모바일 게임 애플리케이션에 특화된 크래시 그룹핑이다.
본 발명의 일 실시예에 따르면, 실제로는 같은 원인에 따른 크래시임에도 불구하고 리포트에 디바이스 모델명, OS 버젼, 게임앱 버젼이 포함되어 다른 크래시인 것처럼 리포트되었던 것을 동일한 크래시로 인식하여 동일한 트러블 슈팅(trouble shooting)을 적용할 수 있다.
효과적인 크래시 리포트 그룹핑을 통하여 효율적인 크래시 관리와 빠른 트러블 슈팅이 가능하다. 이에 따라, 애플리케이션 유지보수 비용이 절감되고 애플리케이션의 수명을 늘릴 수 있다.
도 1은 본 발명에 따른 크래시 리포트 그룹핑을 수행하는 시스템의 개략적인 구성도이다.
도 2는 본 발명에 따른 크래시 리포트 그룹핑 서버(40)의 일례의 내부 구성도이다.
도 3a 및 3b는 본 발명의 일실시예에 따른 크래시 리포트 그룹핑 서버의 처리 과정을 나타낸 순서도이다.
도 4는 도 3b에 따른 크래시 리포트 그룹핑 서버의 동작 중에서 2차 크래시 리포트 그룹핑(S320) 과정을 상세히 설명하는 순서도이다.
도 5는 1차 및 2차 크래시 리포트 그룹핑과, 대표 크래시 리포트 DB(207) 구조를 설명하는 도식도이다.
본 명세서에서 사용되는 용어는 다음과 같이 정의하되, 본 발명에 부합하는 범위 내에서 본 기술 분야에서 통용되는 의미도 포함할 수 있다.
- 크래시(Crash)는 컴퓨터 또는 프로그램 자체가 실행 도중 정지하는 것을 의미한다.
- 크래시 리포트(Crash Report)는 사용자 단말에서 일어난 크래시에 대한 모든 정보를 크래시 리포트 앱 또는 모듈이 캐치하여 정리한 리포트로서, 크래시 로그 파일이 그 일례이다. 크래시 로그 파일에는 헤더, 스택 트레이스, 크래시 발생 위치, CPU 사용량, 또는 크래시 캡쳐 사진 등 크래시에 관한 다양한 정보가 포함될 수 있다.
- 예외(Exception)는 프로그램 실행 중에 발생할 수 있는 예기치 않은 오류를 의미한다.
- 크래시 예외 타입은 크래시 로그 파일 중 헤더 또는 스택 트레이스 필드에 기재되어 있는 것으로, 예외 타입은 단말기 애플리케이션에 연관된 크래시 리포팅 모듈이 캐치한 후 로그 파일에 기재하여 서버로 보내온다. 예외 타입의 유형은 크게 POSIX 신호 유형과 Exception 유형이 있다. POSIX 신호란 유닉스 계열, POSIX 호환 운영체제에서 쓰이는 프로세스 신호로 운영체제에서 프로세스의 예외적인 상황을 보고한다. 신호 종류에 따라 해당 신호를 받은 프로세스는 이를 무시하거나, 이후 진행이 불가능하거나, 프로그램을 중지 시키는 등의 처리를 한다. POSIX 신호의 예로서 SIGABRT(프로세스 중단 신호), SIGBUS(정의되지 않은 메모리 오브젝트의 일부분에 접근), SIGFPE(오류가 있는 산술 조작), SIGILL(유효하지 않은 명령),　SIGSEGV(잘못된 메모리 참조) 등이 있다. Exception의 예에는 NullReferenceException(객체주소가 없음), IndexOutOfBoundException(객체배열에서 지정된 인덱스가 참조할 수 없음), IllegalStateException(객체상태가 메쏘드 호출에 적합하지 않음) 등이 있다.
- 크래시 위치(location)는 실제 크래시가 발생한 플랫폼, 언어계층 또는 애플리케이션 개발엔진의 종류를 의미한다. iOS/Android(운영체제), Java/C#(Virtual Machine 언어), Native(하드웨어 친화적인 저레벨 언어, 운영체제가 구현된 언어), 게임엔진종류(Unity, Unreal, cocos2d 등)로 구분될 수 있다. 예를 들어, Android Unity Native Crash, iOS Native Crash, Java Exception, Android C# Script Exception, Android Native Crash 등이 있다.
Java Exception과 Android C# Script Exception은 엄밀히 구분하면 애플리케이션의 예외이나 본 발명에서 크래시로 분류하는데, 스택 트레이스에 클래스와 메쏘드 명이 상세히 나온다. Android Unity Native Crash는 예외적인 경우로서 NDK에서 크래시를 캐치하기 전에 Unity 단에서 직접 크래시를 캐치하여 스택 트레이스를 만들어 보내주는데, 별도의 매핑 과정은 필요가 없다. Android 및 iOS Native Crash인 경우 크래시가 발생하였을 때 메모리 주소 덤프파일로 떨어지기 때문에 쉽게 식별할 수 있는 클래스로 매핑하기 전에는 메모리 주소로 된 스택 트레이스를 이용하여 그룹핑을 진행할 수 있다. 쉽게 식별할 수 있는 클래스, 메쏘드 이름으로 메모리 주소들이 매핑되면 의미있는 메쏘드 라인을 구별하여 그룹핑을 진행할 수 있다.
- 메소드(Method)는 어떤 로직을 수행하는 함수이다.
- 스택 트레이스(Stacktrace)는 오류가 발생했을 때의 시점 및 그 이전의 메쏘드, 클래스, 라이브러리 호출 목록을 의미하는데, 복수개의 라인으로 구성되어 있다.
- 크래시 그룹 타입은 크래시 스택 트레이스에 나타난 트러블 슈팅에 용이한 라인들 중 최상위 코드 구현 레벨을 구분하는 크래시 타입으로서, 애플리케이션 크래시 그룹, 애플리케이션 개발 엔진 크래시 그룹, 시스템 크래시 그룹이 있다. 크래시 그룹 타입의 순위는 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 순으로 높다.
- 그룹핑(Grouping)은 같은 종류의 것으로 분류하거나 묶는 것을 의미한다.
- 시스템 라이브러리, 클래스 또는 메쏘드는 Device, OS, OS-SDK 관련 라이브러리, 클래스 또는 메쏘드를 포함하고, 시스템 라이브러리는 시스템 프레임워크(System Framework)라고도 한다.
- 루트 코즈(Root Cause)는 어느 사건의 근본적인 원인을 의미한다.
- 심볼화(Symbolication)는 16진수로 표시된 주소들을 심볼(Symbol) 파일들을 이용해서 함수명으로 매핑하여 스택 트레이스를 사람이 읽을 수 있는 형식으로 변환하는 작업이다.
- NDK(Native Development Kit)는 안드로이드(Android)의 SDK(Android Software Development Kit)외에 직접 안드로이드 기본 인터페이스를 프로그래밍할 수 있도록 C/C++ 네이티브 개발을 지원하는 개발 도구이다.
- 네이티브 크래시(Native Crash)는 프로그램 실행 중 발생한 크래시 중 자바(Java)나 C# Script과 같은 애플리케이션 단이 아닌 단말 OS의 네이티브(Native) 단에서 캐치(catch)된 크래시이다.
- 게임 엔진(Game Engine)은 게임 개발을 위한 다양한 기능을 제공하는 소프트웨어 기반 툴(프레임워크)로서, 게임 개발엔진으로도 불리운다.
- 유니티(Unity)는 다양한 플랫폼을 제공하는 Unity사의 게임 엔진이다.
이하, 첨부된 도면을 참조하여 본 발명에 따른 실시예를 상세하게 설명한다. 본 발명의 구성 및 그에 따른 작용 효과는 이하의 상세한 설명을 통해 명확하게 이해될 것이다.
본 발명의 상세한 설명에 앞서, 동일한 구성요소에 대해서는 다른 도면상에 표시되더라도 가능한 동일한 부호로 표시하며, 공지된 구성에 대해서는 본 발명의 요지를 흐릴 수 있다고 판단되는 경우 구체적인 설명은 생략하기로 함에 유의한다.
도 1은 본 발명에 따른 크래시 리포트 그룹핑을 수행하는 시스템의 개략적인 구성도로서, 사용자 단말기(10), 크래시 리포트 그룹핑 서버(20), 애플리케이션 서버(30) 및 네트워크(40)를 포함할 수 있다. 사용자 단말기(10)는 애플리케이션 사용자가 가지고 있는 단말기를 말한다. 네트워크는 유선 또는 무선 네트워크가 될 수 있다. 이하에서 예로써 애플리케이션(101)은 게임 애플리케이션이고, 애플리케이션 서버(30)는 게임 서버이며, 사용자 단말기(10)는 모바일 단말기일 수 있다. 모바일 단말기일 경우, 스마트폰이나 태블릿 PC 등의 모바일 디바이스이나 게임 애플리케이션을 설치하여 실행할 수 있는 기기라면 어떠한 종류의 디바이스라도 가능하다. 사용자 단말기(10)는 게임 애플리케이션을 설치하고 게임 서버(30)에 접속하여 게임을 진행한다. 사용자 단말기(10)에 설치된 게임 애플리케이션(101)에는 크래시 리포팅 모듈(102)이 내장되어 있을 수 있다. 크래시 리포팅 모듈(102)은 애플리케이션에서 발생되는 크래시를 캐치하여 크래시 로그파일을 생성한 후 크래시 리포트 그룹핑 서버(20)로 송신될 수 있도록 하는 기능을 수행한다.
게임 서버(30)는 게임개발업체가 구축하여 운영 및 관리하거나 복수의 게임을 서비스하는 업체나 퍼블리싱(publishing) 업체가 게임개발업체로부터 넘겨받아 직접 운영 및 관리할 수 있다. 크래시 리포트 그룹핑 서버(20)는 사용자 단말기(10)에서 게임 진행시 발생되는 크래시 리포트(예, 크래시 로그 파일)을 수신하여 크래시 유형을 분석하여 그룹핑을 수행한다. 크래시 리포트 그룹핑 서버(20)는 게임 서버(30)와 구별되는 구성으로 되어 게임개발업체 또는 퍼블리싱 업체에 위치할 수 있다. 또는, 도 1과 달리 크래시 리포트 그룹핑 서버(20)는 애플리케이션 서버(30) 내의 일부로 구성될 수도 있다.
그룹핑된 크래시 리포트는 트러블 슈팅(trouble shooting)을 위하여 게임 개발자에게 전송된 후, 게임 애플리케이션이 업데이트되고 사용자 단말기에 다운로드 될 것이다(미도시).
도 2는 본 발명에 따른 크래시 리포트 그룹핑 서버(40)의 일례의 내부 구성도이다. 크래시 리포트 수신부(201)가 사용자 단말기(10)로부터 크래시 로그파일을 수신하여 크래시 리포트 그룹핑 서버(40)의 각 구성부분에 전달한다. 크래시 위치 확인부(202)는 크래시 로그 파일을 수신하고 로그 파일내 필드 중 헤더 또는 스택 트레이스가 존재하는 필드와 구별되는 별도의 필드에 기록된 크래시가 발생한 위치 정보를 크래시 위치 DB(212)를 참조하여 확인한 후 크래시 리포트 매칭부(206)로 보낸다. 크래시 발생위치는 플랫폼, 언어계층 또는 게임엔진 종류 또는 이들의 조합으로 표기될 수 있다. 구체적인 예에서, 플랫폼은 iOS 또는 Android 운영체제이고, 상기 언어 계층은 Java 또는 C# 가상머신(VM) 언어계층, 또는 C 또는 C++ Native 언어계층이고, 상기 게임 애플리케이션 개발엔진 종류는 Unity, Unreal 또는 cocos2d이다. 상기 크래시 위치는 Android 크래시인 경우는 Java Exception, Android Unity Native Crash, Android Native Crash 및 C# Script Exception 중 하나이고, iOS 크래시인 경우는 iOS Native Crash 및 C# Script Exception 중 하나일 수 있다.
크래시 예외 타입 확인부(203)는 크래시 예외 타입 DB(213)을 참조하고, 크래시 로그 파일내 헤더(Header) 또는 스택 트레이스내에 기재된 크래시 예외 타입을 확인하여, 해당 정보를 크래시 리포트 매칭부(206)로 보낸다.
스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)는 크래시 리포트 수신부(201)로부터 혹은 심볼화부(210)로부터 크래시 로그파일을 수신한 후, 크래시 리포트를 서로 구분하는데 유용한 라인만 유지하고 나머지 라인은 제거하여 정제된 스택 트레이스를 추출하여 크래시 리포트 매칭부(206) 및/또는 크래시 그룹 타입 분류부(205)로 보낸다. 상기 라인 제거는 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 먼저 제거한 후, 애플리케이션 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 제거하되, 스택 트레이스의 라인별로 시스템 또는 개발엔진 라이브러리 이름, 클래스 이름 또는 메쏘드 이름을 확인하고 스택 트레이스 라인 DB(214)를 참조하면서 라인 제거를 진행한다. 스택 트레이스 라인 DB(214)에는 시스템 라인들, 애플리케이션 개발엔진 라인들 및 애플리케이션 라인들에 각각 관련된 라이브러리 이름, 클래스 이름 및 메쏘드 이름의 데이터가 저장되어 있다.
크래시 리포트 수신부(201)로부터 수신한 스택 트레이스에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하고 애플리케이션에 관련된 라인들을 남기되, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남긴다.
구체적으로, 만일 상기 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부를 제거한 후 스택 트레이스에 어떠한 라이브러리 이름을 포함하는 라인도 존재하지 않으면, 상기 제거된 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부 또는 전부를 회복시켜서, 정제된 스택 트레이스로 추출한다. 일부 라인들만 회복시킬 경우, 회복되는 일부 스택 트레이스 라인들은 크래시 리포트들을 서로 구분하는데 유용한 라인들이고, 회복되지 못하거나 제거되는 스택 트레이스 라인들은 크래시 리포트들 사이에 공통되는 라인들 또는 스택 트레이스 라인의 일부 정보가 누락된 라인들, 또는 런타임마다 달라지는 메쏘드를 포함하는 라인 등 크래시 리포트 구분에 유용하지 않은 라인들이다. 만일, 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있으면, 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있는지를 확인한다. 만일, 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하지 않으면, 상기 제거된 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부 또는 전부를 회복시켜서, 정제된 스택 트레이스로서 추출한다. 만일, 스택 트레이스에 라이브러리 이름을 포함하는 개발엔진 관련 라인들을 전부 제거한 후에도 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하면, 남아있는 스택 트레이스의 라인을 정제된 스택 트레이스로 추출한다.
전술한 제거 방식에 따르면, 스택 트레이스에 시스템에 관련된 라인들, 애플리케이션 개발엔진에 관련된 라인들, 애플리케이션에 관련된 라인들이 모두 있는 경우는 애플리케이션에 관련된 라인들만 남아 정제된 스택 트레이스로 추출된다. 그런데, 애플리케이션 라이브러리 이름을 포함하는 라인들의 일부를 제거할 수도 있는데, 상기 제거되는 애플리케이션 라이브러리 이름을 포함하는 라인은 크래시 리포트들을 서로 구분하는데 유용하지 않은 라인들로서, 애플리케이션 개발엔진 클래스 또는 메쏘드 이름을 포함하는 라인이거나, 서로 중복된 라인, 또는 크래시 리포트들 사이에서 공통되는 라인들, 또는 일부 정보가 누락된 라인들, 또는 런타임마다 달라지는 메쏘드를 포함하는 라인들이 해당될 수 있다.
스택 트레이스는 헤더와 구분될 수 있으나, 만일 스택 트레이스가 헤더를 포함하는 경우라면 상기 제거기능은 스택 트레이스에서 헤더도 제거하는 것을 포함할 수 있다.
상기 스택 트레이스 라인 제거없이 아래와 같이 정제된 스택 트레이스 추출도 가능할 수 있다. 즉, 스택 트레이스 라인들에서 애플리케이션에 관련된 라인들이 있으면 그 일부 또는 전부를 먼저 추출하여 정제된 스택 트레이스로 한다. 만일, 애플리케이션에 관련된 라인이 없는 경우, 애플리케이션 개발엔진에 관련된 라인들이 있는지를 확인하고 존재하면 그 일부 또는 전부를 정제된 스택 트레이스로서 추출한다. 애플리케이션 및 애플리케이션 개발엔진에 관련된 라인이 없는 경우, 남아있는 라인들, 즉 시스템에 관련된 라인들의 일부 또는 전부를 정제된 스택 트레이스로서 추출할 수 있다.
크래시 그룹타입 분류부(205)는 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)로부터 정제된 스택 트레이스 라인들을 수신한 후, 이 라인들이 관련된 크래시 그룹타입을 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 중 어느 하나의 타입으로 분류하고, 그 정보를 크래시 리포트 매칭부(206)로 보낸다. 이와 선택적으로, 크래시 그룹타입 분류부(205)는 크래시 리포트 수신부(201)로부터 크래시 로그 파일을 받아서, 트러블 슈팅에 용이한 라인들 중에서 최상위 코드 구현 레벨을 구분해내도록 구성할 수도 있다. 구체적으로, 상기 크래시 그룹 타입의 순위는 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 순으로 높은데, 상기 크래시 그룹 타입은 상기 제거 단계전 스택 트레이스 라인들을 각 라인별로 검토하면서 관련된 각 크래시 그룹을 확인하되 관련된 크래시 그룹들 중에서 최상위 크래시 그룹을 해당 로그 파일의 크래시 그룹타입으로 분류할 수 있다.
실시예에 따라서 크래시 그룹타입 분류부(205)에 의해 수행되는 크래시 그룹타입 분류는 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)에서 함께 수행될 수도 있다.
스택 트레이스 해싱부(208)는 예를 들어, 크래시 위치(crash location)가 AOS 또는 iOS의 Native Crash 경우, 스택 트레이스 라인들이 메모리 주소값을 포함할 수 있는데, 해시 알고리즘을 사용하고 스택 트레이스 해싱 DB(209)를 참조하여 메모리 주소값을 포함하는 스택 트레이스 라인들에 대응하는 고정된 길이의 키값인 해시 키를 생성할 수 있다.
심볼화부(210)는 심볼화 DB(211)을 참조하여 스택 트레이스 라인들의 메모리 주소값에 대응하는 클래스 이름 및/또는 메쏘드 이름으로 매핑한다. 만일 심볼화가 실패한 경우, 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)는 기능을 수행할 수 없고, 스택 트레이스 해싱부(208)에서 생성된 해시 값이 크래시 리포트 매칭부(206)에서 활용될 수 있다.
반면, 스택 트레이스 라인에 메모리 주소값이 아닌, 라이브러리 이름, 클래스 이름 및/또는 메쏘드 이름으로 구성되어 있는 경우는 스택 트레이스 해싱부(208)와 심볼화부(210)는 해싱 및 심볼을 각각 수행할 수 없고, 필요가 없다.
크래시 리포트 매칭부(206)는 크래시 위치 확인부(202)로부터 수신한 크래시 위치, 크래시 예외 확인부(203)로부터 수신한 예외 타입, 정제된 스택 트레이스 추출부(204)로부터 수신한 추출된 정제된 스택 트레이스, 이 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인을 대표 크래시 리포트 DB(207)에 저장된 원인별 대표 크래시 리포트들의 크래시 위치, 예외 타입, 정제된 스택 트레이스, 루트 코즈 라인과 비교하여 매칭되는 대표 크래시 리포트를 확인해낸다. 해당 게임 애플리케이션을 식별하는 앱코드도 서로 비교하여 매칭에 활용할 수 있다(미도시).
또한, 크래시 그룹타입 분류부(205)로부터 수신한 크래시 그룹 타입을 대표 크래시 리포트의 크래시 그룹 타입과 비교하여 매칭하는데 활용할 수 있다. 애플리케이션 크래시 그룹타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스가 상호 동일한 경우 매칭되는 것으로 판단할 수 있다. 개발엔진 크래스 그룹타입이거나 시스템 크래시 그룹타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스가 상호 유사한 경우 매칭되는 것으로 판단할 수 있다. 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스의 상호 유사 여부는 루트 코즈 라인은 서로 동일하고, 상호 일치하는 스택 트레이스의 라인 개수의 비율이 일정 퍼센트 이상, 예를 들어, 70% 이상이면 유사한 것으로 보고 매칭된다고 판단할 수 있다.
만일 매칭이 되는 대표 크래시 리포트가 없는 경우, 상기 크래시 위치, 상기 예외 타입, 상기 크래시 그룹 타입, 상기 루트 코즈 라인 및 상기 추출된 정제된 스택 트레이스를 포함하는 새로운 대표 크래시 리포트로 분류하고, 대표 크래시 리포트 DB(207)에 저장한다.
크래시 위치가 Andorid Native Crash 또는 iOS Native Crash이나 심볼화부(210)에서 심볼화가 실패한 경우, 크래시 리포트 매칭부(206)는 크래시 위치, 예외 타입 및 스택 트레이스의 해시 값을 대표 크래시 리포트 DB를 참조하여 대표 크래시 리포트들의 크래시 위치, 예외 타입 및 스택 트레이스의 해시 값과 비교하여 매칭여부를 판단할 수 있다.
크래시 리포트 매칭부(206)는 크래시 위치, 예외 타입, 앱코드를 기준으로 매칭여부를 판단하여 1차 크래시 리포트 그룹핑을 한 후, 크래시 그룹 타입, 루트 코즈 라인, 정제된 스택 트레이스를 기준으로 상기 매칭여부를 추가 판단하는 2차 크래시 리포트 그룹핑을 수행할 수 있다. 대표 크래시 리포트 DB(207)는 앱코드별로 구성되고, 각 앱코드별 DB내에는 다수의 대표 크래시 리포트들 중 예외 타입 및 크래시 위치가 동일한 대표 크래시 리포트들을 하나의 1차 그룹으로 구분하는 방식으로 된 복수개의 1차 그룹이 포함될 수 있다. 각각의 1차 그룹내에는 크래시 그룹타입, 루트 코즈 라인, 정제된 스택 트레이스 또는 스택 트레이스 해시값이 동일한 대표 크래시 리포트들(또는 이들 동일한 항목들은 스택 트레이스와 관련된 것이므로, 대표 스택 트레이스라고도 명명할 수 있음)을 하나의 2차 그룹으로 분류하는 방식으로 된 복수개의 2차 그룹이 포함될 수 있다. 이에 따라, 전술한 1차 및 2차 크래시 리포트 그룹핑을 통한 매칭을 효과적으로 수행할 수 있다.
다음 표 1은 앞서 설명한 대표 크래시 리포트의 포맷을 요약한 것이다. 아래 표 1에서 좌측열에 있는 정보는 1차 크래시 리포트 그룹핑에 활용되고, 우측열에 기재된 정보는 2차 크래시 리포트 그룹핑에 활용될 수 있다. 우측열에 표시된 정보 중에서 '라인수(스택 트레이스 라인 개수)'는 그룹핑 속도 개선을 위한 속성으로서 그룹핑을 위한 비교에서 필수적인 특징은 아니다.
앱 코드- 게임 애플리케이션별 코드 그룹 타입(아래 타입 중 하나)- 게임 크래시- 엔진 크래시- 시스템 크래시
크래시 위치(아래 크래시 위치의 예시 중 하나) - Android Java Exception- Android Unity Native Crash- Android Native Crash- Android C# Script Exception- iOS Native Crash- iOS C# Script Exception
라인 수- 스택 트레이스 라인 개수
루트 코즈 라인- 크래시 원인 라인
예외 타입(아래 예외 타입의 유형 중 하나)- POSIX 시그널- Exception 이름 스택트레이스(아래 데이터 중 하나)- 정제된 스택 트레이스- 스택 트레이스 해시 값
도 3a 및 3b는 본 발명의 일실시예에 따른 크래시 리포트 그룹핑 서버의 처리 과정을 나타낸 순서도이다. 크래시 리포트 수신부(201)가 크래시 리포트를 수신한 후(S300), 크래시 위치, 예외 타입, 앱 코드를 식별하고(S302 및 도 2의 202, 203 참조), 이 정보를 토대로 크래시 리포트 매칭부(206)에서 1차 크래시 리포트 그룹핑을 수행한다(S304). 다음으로, 크래시 예외 타입이 Android Native Crash이거나 iOS Native Crash인지 여부를 확인하고(S306), 만일 이와 다른 예외 타입으로 확인이 되면, 스택 트레이스에서 시스템 관련 라인들을 라인별(line by line)로 확인하며 제거한다(S308). S308 단계이후, 스택 트레이스 라인이 남아 있는지 확인하고(S310), 스택 트레이스 라인이 남아 있으면 스택 트레이스에서 애플리케이션 개발엔진 관련 라인을 제거하고(S312), S310 단계에서 남은 스택 트레이스 라인이 없는 것으로 확인하면 제거한 시스템 관련 스택 트레이스 라인의 일부를 회복한다(S322). 단계 S312를 통한 스택 트레이스 라인제거 후에도 스택 트레이스 라인이 남아 있는지 확인(S314)하고, 남아 있지 않으면 제거된 애플리케이션 개발엔진 관련 라인의 일부를 회복시킨다(S324). 단계 S322와 S324에서 회복되는 일부 라인과 회복되지 않고 제거되는 일부 라인들에 대한 판단 기준은 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)와 관련하여 전술한 바와 같다. 구현례에 따라서 단계 S322와 S324에서 선택적으로 회복하지 않고 제거된 전체 라인을 회복시킬 수도 있다. 단계 314를 거쳐 남은 스택 트레이스 라인, 즉, 애플리케이션 관련 스택 트레이스 라인들, 또는 단계 322와 단계 324를 통해 회복된 시스템 관련 라인들 또는 개발엔진 관련 라인들은 정제된 스택 트레이스로서 추출되고, 정제된 스택 트레이스에서 최상위 라인, 즉 맨 앞쪽 라인은 루트 코즈 라인으로 추출된다(S316). 추출된 정제된 스택 트레이스는 시스템, 애플리케이션 개발엔진, 애플리케이션 중 어느 하나와 관련되어 있으므로, 그 관련성을 바탕으로 크래시 그룹 타입을 분류한다(S318). 추출된 정제된 스택 트레이스, 루트 코즈 라인, 크래시 그룹 타입을 바탕으로, 앞서 1차 분류된 크래시 리포트 그룹내의 복수의 서브 그룹 중에서 매칭되는 크래시 리포트 서브 그룹(2차 그룹)을 확인한다(S320).
전술한 단계 S306에서 예외 타입이 Android Native Crash 또는 iOS Native Crash인 경우는 스택 트레이스를 해싱(S326)하고 심볼화(S328, S330)를 거쳐서 시스템관련 라인을 제거하는 단계(S308)로 밟게 된다. 단계 S326과 S328은 순서가 바뀌어도 가능하다. S328에서 심볼화가 가능하지 않는 경우, 단계 S326를 통해 생성된 스택 트레이스 해시 값을 이용하여 2차 크래시 리포트 그룹핑(S320)을 진행할 수 있다.
도 4는 도 3b에 따른 크래시 리포트 그룹핑 서버의 동작 중에서 2차 크래시 리포트 그룹핑(S320) 과정을 상세히 설명하는 순서도이다. 먼저, 스택 트레이스 라인이 해시값으로 정의되어 있는 지를 확인하고(S400), 만일 그렇지 않으면, 추출된 정제된 스택 트레이스가 애플리케이션 크래시 그룹타입 여부를 확인한다(S402). 애플리케이션 크래시 그룹타입인 경우, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207)에 저장된 기분류된 동일한 1차 크래시 리포트 그룹내에 있는 다수의 대표 크래시 리포트들의 정제된 스택 트레이스('대표 스택 트레이스'로 칭함)와 각각 비교하여 서로 동일한 스택 트레이스가 있는 지를 판단한다(S404). 동일한 대표 스택 트레이스가 있으면 해당 대표 스택 트레이스로 매칭하고(S406), 동일한 대표 스택 트레이스가 없으면, 추출된 정제된 스택 트레이스를 신규 대표 스택 트레이스로 대표 크래시 리포트 DB(207) 내의 기분류된 동일한 1차 크래시 리포트 그룹내에 추가한다(S412).
단계 S402에서 애플리케이션 크래시 그룹타입이 아닌 경우, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207)에 저장된 기분류된 동일한 1차 그룹내의 다수의 대표 스택 트레이스와 각각 비교하여, 루트 코즈 라인이 동일하고(S408) 상호 일치하는 스택 트레이스 라인의 개수가 예를 들어, 70% 이상인지를 확인하고(S410), 두 조건을 만족하는 대표 스택 트레이스에 매칭한다(S406). 만일 위 두 조건 중 적어도 어느 하나를 만족하지 못하면, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207) 내 기분류된 동일한 1차 그룹내에 추가한다(S412).
단계 S400에서 수신된 스택 트레이스 라인이 해시값으로 정의되어 있으면, 수신된 스택 트레이스의 해시값을 기분류된 동일한 1차 그룹내에 있는 다수의 대표 스택 트레이스의 해시값과 각각 비교하여 동일한 대표 스택 트레이스를 확인한다(S414). 해시값이 동일한 기존의 대표 스택 트레이스가 있으면 이 대표 크래시 리포트로 매칭시키고(S406), 해시값이 동일한 기존 대표 스택 트레이스가 없으면 신규 대표 스택 트레이스로 대표 크래시 리포트 DB(207) 내 기분류된 1차 그룹에 추가한다(S412).
다음은 크래시 로그파일의 헤더와 스택 트레이스 샘플을 통해 본 발명을 설명한다. 설명 편의를 위하여 로그파일 라인에 일련 번호를 부여하였다.
[샘플 1]
1 java.lang.Error: signal 11 (SIGSEGV), code 0 (?), fault addr 0000361b
2 Build fingerprint: 'samsung/arubaslimxx/arubaslim:4.1.2/JZO54K/I8262XXAND1:user/release-keys'
Revision: '0'
3 pid: 13851, tid: 16562, name: UnityMain >>> com.netmarble.mherosgb <<<
4 r0 00000000 r1 0000000b r2 00000001 r3 400fe7ac
5 r4 53a26c04 r5 5ef09ec0 r6 68781de8 r7 00000025
6 r8 00000000 r9 59c374b0 sl 6465f9b0 fp 5484dcd4
7 ip fffd406c sp 5484dcb8 lr 53926370 pc 400c7cf8 cpsr 354f5a4a
8 at libc.kill(kill:12)
9 at libmono.002ad36c(Native Method)
10 at libmono.002ad468(Native Method)
11 at libmono.002ad4c4(Native Method)
12 at libmono.0011b2b4(Native Method)
13 at libmono.0011b550(Native Method)
14 at libmono.0011bbc4(Native Method)
15 at libmono.0012a750(Native Method)
16 at libmono.000ede20(Native Method)
17 at Summoners.GetSummoner(Native Method)
18 at Summoners.GetSummoner(<0x00128>:296)
19 at Summoners.SummonMyFriend(<0x00027>:39)
20 at ClickSummon.OnClick(<0x000b7>:183)
21 at Object.runtime_invoke_void__this__(Native Method)
22 at GameObject.SendMessage(Native Method)
23 at UICamera.Notify(<0x00068>:104)
24 at UICamera.ProcessTouch(<0x00bbf>:3007)
25 at UICamera.ProcessTouches(<0x003d3>:979)
26 at UICamera.Update(<0x000ff>:255)
27 at Object.runtime_invoke_void__this__(Native Method)
28 at libmono.00023bbb(Native Method)
29 at libmono.mono_runtime_invoke(mono_runtime_invoke:136)
30 at libunity.00216e6c(Native Method)
31 at libunity.002d63ec(Native Method)
32 at libunity.002d63a8(Native Method)
33 at libunity.0020243c(Native Method)
34 at libunity.00202450(Native Method)
35 at libunity.001e8e3c(Native Method)
36 at libunity.001e9384(Native Method)
37 at libunity.002a0e14(Native Method)
38 at libunity.003d3c1c(Native Method)
앱코드는 라인 3번에 표시된 'mherosgb'인데 도시가 생략된 앱코드 확인부 및 앱코드 DB를 참조하여 확인할 수 있다. 크래시 위치가 표시된 크래시 로그파일의 필드는 위 샘플에 표시되지 않았는데, "Crash location: Android Unity Native Crash"라는 로데이터(raw data)가 확인된 것으로 가정한다. 크래시 위치는 Crash location이라는 별도의 필드 제목을 포함하여 수신하므로 확인이 용이하고 DB(212)를 참조하여 컨펌할 수 있는데, 스택트레이스/헤더와 별개의 필드에 존재할 수 있고, 메모리/CPU 사용량 등과 같은 형식으로 전달될 수 있다. 그리고 설명의 편의상 하기의 각 기능을 수행하는 도 2의 구성요소의 특정은 본 샘플 설명에서 설명에 필요한 최소한으로만 언급하고, 설명의 순서는 도 3 내지 도 4의 순서도에 최대한 부합하도록 설명한다. 라인 1 내지 7은 헤더에 해당하는데, 크래시 예외 타입 DB(213)에 기록된 크래시 예외 타입 중 POSIX 신호 유형의 하나인 SIGSEGV을 라인 1에서 크래시 예외 타입 확인부(203)가 확인할 수 있다. SIGSEGV는 잘못된 메모리 참조를 의미하는 예외 타입이다. 이들 정보로 1차 크래시 리포트 그룹핑이 가능하다.
다음으로, 크래시 위치가 Android Unity Native Crash이므로 스택 트레이스 라인 제거단계로 진행한다. 라인 8 내지 라인 38로 이루어진 스택 트레이스에서 스택 트레이스 라인제거부 및 정제된 스택트레이스 추출부(204)가 라인 8부터 순차적으로 내려가면서 스택 트레이스 라인 DB(214)를 참조하여 시스템에 관련된 라인을 제거한다. 라인 8은 libc가 시스템 라이브러리 이름, kill이 시스템 관련 메쏘드, 12가 위치를 의미하므로 시스템 관련 스택 트레이스 라인에 해당되어 제거된다. 라인 9 내지 라인 38까지 시스템 관련 라인은 발견되지 않는다. 시스템 관련 라인 제거 후에도 다수의 스택 트레이스 라인(라인 9 내지 38)이 남아 있으므로, 다음으로 애플리케이션 개발엔진 관련 라인을 제거한다. 라인 9는 libmono가 게임 개발엔진 라이브러리 이름, 002ad36c가 메쏘드의 주소, Native Method가 Native 언어로 구현된 메쏘드를 의미를 의미하므로 게임 개발엔진 라인에 해당되어 제거된다. 같거나 유사한 이유로 스택 트레이스 라인 DB(209)를 참조하면서 라인 10 내지 16, 라인 21 내지 라인 38을 순차적으로 제거한다. 게임 개발엔진 라인 제거 후에도 스택 트레이스 라인 17 내지 20이 남아 있다. 이들 라인은 애플리케이션 관련 라인들이다. 이들 라인들을 정제된 스택 트레이스로 추출하고, 최상위 라인 17을 루트 코즈 라인으로 할 수 있다. 그런데, 더 효과적인 그룹핑을 위해서 남아 있는 애플리케이션 관련 라인들 중에서 위치 정보가 없는 라인들은 추가로 삭제하도록 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)를 설정할 수 있다. 그러한 경우, 17 내지 20 중에서 위치 정보가 없는 라인 17을 추가로 삭제하고, 라인 18 내지 20을 정제된 스택 트레이스로 추출하고, 라인 18을 루트 코즈 라인으로 추출할 수 있다. 그리고, 추출된 정제된 스택 트레이스가 게임(애플리케이션) 관련 트레이스 라인들이므로, 크래시 그룹 타입을 게임(애플리케이션) 그룹 타입으로 분류한다.
해시 값으로 표시되지 않는 정제된 스택 트레이스가 추출되었고, 게임 크래시 그룹 타입이므로, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207) 내의 1차 그룹핑된 그룹내의 여러 서브 그룹의 대표 스택 트레이스와 각각 비교하면서, 동일한 대표 스택 트레이스를 검색하여 매칭한다. 매칭되지 않으면, 대표 크래시 리포트 DB(207)내의 1차 그룹내에 신규 서브그룹을 만들고 신규 대표 스택 트레이스로 저장한다.
이렇게 추출된 정제된 크래시 리포트는 특히, 루트 코즈 라인과 스택 트레이스를 보고 트러블 슈팅을 위한 단서를 유추하는데 사용될 것이다. 위 샘플 1의 경우, 게임 개발자가 구현한 게임 로직 중에서 Summoner라는 객체를 얻는 GetSummoner 메쏘드가 실행되다가 잘못된 메모리를 참조하는 로직이 수행되어 크래시가 생겼다고 유추할 수 있다.
[샘플 2]
아래 샘플은 심볼화 과정을 거친 후의 iOS Native Crash 로그의 스택 트레이스 중 일부를 발췌한 것이다.
Full2016 EventDelegate_Execute_m213950963 (in full2016) (Bulk_Assembly-CSharp_4.cpp:10246)
Full2016 EventDelegate_Execute_m895247138 (in full2016) (Bulk_Assembly-CSharp_4.cpp:10904)
Full2016 UIButton_OnClick_m1558826940 (in full2016) (Bulk_Assembly-CSharp_22.cpp:11351)
Full2016 RuntimeInvoker_Void_t2863195528(MethodInfo const*, void*, void**) (in full2016) (Il2CppInvokerTable.cpp:1262)
iOS의 경우, 게임엔진 라이브러리 이름이 별도로 없고 게임 라이브러리 이름만 존재하므로, 게임엔진 관련 스택 트레이스 라인은 게임엔진에 관한 클래스 명칭 또는 메쏘드 명칭을 통해 구분할 수 있다. 위 샘플 2의 각 스택 트레이스 라인의 라이브러리 이름은 Full2016인데 이 라이브러리 이름은 게임 라이브러리와 게임엔진 라이브러리가 공통으로 사용하는데, 이어서 기재된 클래쓰(예, EventDelegate)와 메쏘드(예, Execute_m213950963)가 게임엔진에 관련된 것이므로, 샘플 2의 모든 스택 트레이스 라인들은 게임엔진 관련 라인으로 이해될 수 있다. 이러한 판단은 스택 트레이스 라인 DB(214)에 저장된 iOS 게임 라이브러리 이름 등의 정보를 바탕으로 가능하게 된다.
[샘플 3]
크래시 위치가 크래시 로그 파일의 다른 필드에서 iOS Native Crash 로그로 확인되었다고 전제하고 아래는 크래시 로그 파일 중 스택 트레이스와 헤더를 발췌한 것이다.
*** Terminating app due to uncaught exception '(null)', reason: '(null)'
Incident Identifier: B1DCB953-DAB0-47EA-AA44-D8F6316C859A
Hardware Model: iPhone5,2
Process: full2016 [1454]
Path: /var/containers/Bundle/Application/6F542B8E-7B13-4C1A-90CC-4EBAAF4BDD85/full2016.app/full2016
Identifier: com.netmarble.full2016
Version: 1231
Code Type: ARM
Parent Process: ??? [1]
Date/Time: 2017-03-12T15:12:06Z
OS Version: iPhone OS 10.2.1 (14D27)
Report Version: 104
Exception Type: SIGABRT
Exception Codes: #0 at 0x1ca24ad4
Crashed Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x1ca24ad4 0x1ca0e000 + 92884
1 libsystem_c.dylib 0x1c9b8339 0x1c96d000 + 308025
2 libc++abi.dylib 0x1c4bc569 0x1c4bb000 + 5481
3 libc++abi.dylib 0x1c4d650f 0x1c4bb000 + 111887
4 libobjc.A.dylib 0x1c4df305 0x1c4d8000 + 29445
5 libc++abi.dylib 0x1c4d393f 0x1c4bb000 + 100671
6 libc++abi.dylib 0x1c4d3443 0x1c4bb000 + 99395
7 libobjc.A.dylib 0x1c4df1bb 0x1c4d8000 + 29115
8 CoreFoundation 0x1d1855a1 0x1d17b000 + 42401
9 CoreFoundation 0x1d185341 0x1d17b000 + 41793
10 GraphicsServices 0x1e95cbfd 0x1e953000 + 39933
11 UIKit 0x22393e67 0x2231a000 + 499303
12 libdyld.dylib 0x1c94f50b 0x1c94c000 + 13579
위 로그파일에서 앱코드는 identifier 필드에 표시된 'full2016'인데 도시가 생략된 앱코드 확인부 및 앱코드 DB를 참조하여 확인할 수 있다.
위 로그파일의 헤더에서 예외타입이 SIGABRT로 기재되어 있으므로, 전술한 크래시 위치 정보와 함께 1차 크래시 리포트 그룹핑을 할 수 있다.
한편, 스택 트레이스 해싱 DB(209)를 참조하여 얻은 스택 트레이스 해시값은 다음과 같다. 만약 심볼화가 성공적으로 되지 않는다면, 이 해시값을 사용하여 대표 스택 트레이스와 매칭 여부를 확인할 것이다. 스택 트레이스 해시값은 해시 알고리즘을 통해 만든 고정된 길이의 데이터 값인데, 아래 해시값은 위 로그파일의 라인 0 내지 12를 해시 알고리즘의 하나인 MD5 알고리즘을 사용하여 만든 값이다.
6ea0ca5491f32bb8db110d15b12ae66d
물론 해시값없이 라인 0부터 라인 12까지 메모리 주소를 포함하는 라인을 그대로 사용하여 크래시 리포트 사이의 동일, 유사성을 비교할 수도 있겠으나, 그러한 경우 효율이 매우 저하될 것이다.
심볼화 DB(211)를 참조하여 성공적으로 심볼화한 스택 트레이스는 아래와 같다.
0 libsystem_kernel.dylib __pthread_kill (in libsystem_kernel.dylib)
1 libsystem_c.dylib abort (in libsystem_c.dylib)
2 libc++abi.dylib __cxa_demangle (in libc++abi.dylib)
3 libc++abi.dylib default_terminate_handler() (in libc++abi.dylib)
4 libobjc.A.dylib objc_terminate() (in libobjc.A.dylib)
5 libc++abi.dylib std::__terminate() (in libc++abi.dylib)
6 libc++abi.dylib __cxa_increment_exception_refcount (in libc++abi.dylib)
7 libobjc.A.dylib objc_begin_catch (in libobjc.A.dylib)
8 CoreFoundation CFSetGetValue (in CoreFoundation)
9 CoreFoundation CFRunLoopRunSpecific (in CoreFoundation)
10 GraphicsServices GSEventRunModal (in GraphicsServices)
11 UIKit stub helpers (in UIKit)
12 libdyld.dylib start (in libdyld.dylib)
스택 트레이스 라인 DB(214)은 각 크래시 그룹타입에 따른 라인들에 대한 정보, 대부분의 스택 트레이스에서 확인되는 범용적인 라인에 대한 정보, 런타임마다 달라지는 메쏘드에 대한 정보 등을 포함할 수 있다. 스택 트레이스 라인 DB(214)를 참조하면서 위 0번 라인부터 12번까지 차례로 시스템 관련 라인인지 여부를 확인해 내려간다. 그 결과, 모두 시스템 관련 라인이므로 0 내지 12번 라인이 모두 삭제되는데, 이 삭제 이후 남아있는 라인이 없게 되므로, 이들 시스템 관련 라인들을 회복하여야 한다. 회복시 라인 0, 1 및 12는 스택 트레이스 라인 DB(214)를 참조하면 대부분의 스택 트레이스에 포함되는 라인이기 때문에 회복시키지 않고 라인 2 내지 11만 회복시킬 수 있다. 이 라인 2 내지 11이 정제된 스택 트레이스로 추출되고, 이 중에서 최상위 라인인 라인 2가 루트 코즈 라인으로 추출된다. 그리고, 크래시 그룹 타입은 시스템 타입으로 분류되므로, 이들 정보로 2차 크래시 리포트 그룹핑을 진행한다. 1차 분류된 그룹내의 서브 그룹들의 대표 스택 트레이스 중에서, 크래시 그룹 타입과 추출된 루트 코즈 라인이 동일하고 라인 2 내지 11 중 7개 이상, 즉 70% 이상 동일한 라인을 가진 대표 스택 트레이스를 검색한다. 검색을 통해 매칭되는 대표 스택 트레이스가 있으면, 해당 서브 그룹에 추출된 정제된 스택 트레이스를 DB(207)에 저장하고, 매칭되는 대표 스택 트레이스가 없으면, 1차 분류된 그룹내에 새로운 서브 그룹의 대표 스택 트레이스로 DB(207)에 저장한다.
도 5는 앞서 설명한 1차 및 2차 크래시 리포트 그룹핑과, 대표 크래시 리포트 DB(207) 구조를 설명하는 도식도이다. 여기서, 1차 그룹핑은 설명 편의상 크래시 예외 타입으로만 분류되었다. 1차 그룹에는 NullReferenceException, IndexOutBoundException, IllgalStateException 등의 그룹으로 구분되어 있고, 각 1차 그룹에 복수개의 서브 그룹이 포함되어 있다. 예를 들어, IndexOutBoundException 그룹내에는 서브 그룹 D, E, F 등이 포함되어 있고, 각 서브그룹에는 대표 스택 트레이스를 포함하고 있다. 그룹핑을 해야 할 새로운 크래시 로그 파일을 수신하면, 크래시 위치, 예외 타입, 앱코드 등의 정보로 위 1차 그룹 중 어느 하나로 먼저 분류한 후, 추출된 정제된 스택 트레이스와 크래시 그룹 타입 등의 정보로 2차 분류를 진행한다.
본 발명의 실시예에 따른 크래시 리포트 그룹핑과 Apteligent의 그룹핑 결과를 비교하였다. 모바일 게임앱은 네이버용 레이븐이 사용되었고, 크래시 종류별로 사용된 로그 파일의 개수는 Java Exception 로그 80개, NDK Native 크래시 로그 200개, iOS Native 크래시 로그 200개로서 총 480개의 로그 파일이 테스트에 사용되었다. 크래시 리포트 그룹핑 결과, Apteligent는 406개 크래시 그룹으로 분류한데 반해, 본 발명의 실시예에 따른 그룹핑 방법은 282개의 크래시 그룹으로 분류하였다. 즉, Apteligent에 비하여 약 30% 정도 그룹 개수가 감소하는 효과를 보였다.
본 발명에 따른 상기 예시적인 방법들은 프로세서에 의해 실행되는 프로그램 명령들, 소프트웨어 모듈, 마이크로코드, 컴퓨터(정보 처리 기능을 갖는 장치를 모두 포함함)로 읽을 수 있는 기록 매체에 기록된 컴퓨터 프로그램 제품, 애플리케이션, 논리 회로들, 주문형 반도체, 또는 펌웨어 등 다양한 방식으로 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD, DVD, 자기 테이프, 하드 디스크, 플로피 디스크, 하드 디스크, 광데이터 저장 장치 등이 있으며, 이에 제한되는 것은 아니다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이상의 설명은 본 발명을 예시적으로 설명한 것에 불과하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 본 발명의 기술적 사상에서 벗어나지 않는 범위에서 다양한 변형이 가능할 것이다.
따라서 본 발명의 명세서에 개시된 실시예들은 본 발명을 한정하는 것이 아니다. 본 발명의 범위는 아래의 특허청구범위에 의해 해석되어야 하며, 그와 균등한 범위 내에 있는 모든 기술도 본 발명의 범위에 포함되는 것으로 해석해야 할 것이다. 그리고, 본 발명의 청구항에 기재된 일부 단계들의 순서는 그 순서가 바뀌어 실시되어도 발명의 구현이 가능하다는 점을 이해할 수 있을 것이다.
[부호의 설명]
10 사용자 단말기
20 크래시 리포트 그룹핑 서버
30 애플리케이션 서버
201 크래시 리포트 수신부
202 크래시 위치 확인부
203 크래시 예외 타입 확인부
204 스택 트레이스 라인 제거부 / 정제된 스택 트레이스 추출부
205 크래시 그룹타입 분류부
206 크래시 리포트 매칭부
207 대표 크래시 리포트 DB
208 스택 트레이스 해싱부
210 심볼화부

Claims (22)

  1. 서버에서 수행되는 크래시 리포트 그룹핑 방법으로서,
    상기 서버와 통신가능한 단말기로부터 상기 단말기에 설치된 애플리케이션에 대한 크래시 리포트를 수신하는 단계,
    상기 수신된 크래시 리포트에서 크래시가 발생한 플랫폼, 언어 계층 또는 애플리케이션 개발엔진 종류를 기준으로 크래시를 구분하는 크래시 위치(crash location)를 확인하는 단계,
    상기 수신된 크래시 리포트에 기재된 크래시의 예외 타입(exception type)을 확인하는 단계,
    상기 크래시 리포트의 스택 트레이스(stack trace)에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하되, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남기는, 상기 스택 트레이스 라인 제거 단계,
    상기 스택 트레이스에서 상기 라인들을 제거하고 남은 정제된 스택 트레이스를 추출하는 단계, 및
    상기 크래시 위치, 상기 예외 타입, 상기 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인(root cause line), 및 상기 추출된 정제된 스택 트레이스를 크래시 원인별 대표 크래시 리포트의 크래시 위치, 예외 타입, 루트 코즈 라인, 및 정제된 스택 트레이스와 비교하여 매칭여부를 판단하는 단계
    를 포함하는 크래시 리포트 그룹핑 방법.
  2. 제1항에 있어서,
    상기 정제된 스택 트레이스 라인들을 기준으로 상기 크래시를 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 중 어느 하나의 크래시 그룹 타입으로 분류하는 단계를 더 포함하고,
    상기 매칭여부 판단 단계에서 상기 크래시 그룹 타입을 비교하는 것을 포함하는 크래시 리포트 그룹핑 방법.
  3. 제1항에 있어서,
    상기 애플리케이션은 모바일 게임 애플리케이션인 크래시 리포트 그룹핑 방법.
  4. 제1항에 있어서,
    상기 애플리케이션에 대한 크래시 리포트는 상기 애플리케이션에 설치된 크래시 리포팅 모듈에서 생성되는 크래시 로그파일이고,
    상기 예외 타입은 상기 크래시 로그 파일의 헤더 또는 스택 트레이스에서 확인할 수 있고,
    상기 크래시 위치는 상기 헤더 또는 스택 트레이스와 구별되는 상기 크래시 로그 파일 내 별도의 필드에서 확인할 수 있는 것인 크래시 리포트 그룹핑 방법.
  5. 제1항에 있어서,
    상기 제거 단계는 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 제거한 후에 애플리케이션 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 제거하는 것인 크래시 리포트 그룹핑 방법.
  6. 제2항에 있어서,
    상기 크래시 그룹 타입의 순위는 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 순으로 높고, 상기 크래시 그룹 타입은 상기 제거 단계전 스택 트레이스에 있는 최상위 크래시 그룹으로 분류하는 것인 크래시 리포트 그룹핑 방법.
  7. 제2항에 있어서,
    상기 스택 트레이스 라인 제거 단계와 상기 크래시 그룹 타입 분류 단계는
    시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부를 제거한 후 스택 트레이스에 어떠한 라이브러리 이름을 포함하는 라인도 존재하지 않으면, 크래시의 그룹 타입을 시스템 크래시 그룹으로 분류하고, 상기 제거된 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부를 회복시키는 단계와,
    상기 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있으면, 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있는지를 확인하는 단계와,
    개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하지 않으면, 크래시 그룹 타입을 개발엔진 크래시 그룹으로 분류하고, 상기 제거된 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부를 회복시키는 단계와,
    개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하면, 크래시 그룹 타입을 애플리케이션 크래시 그룹으로 분류하는 단계를 포함하는
    크래시 리포트 그룹핑 방법.
  8. 제7항에 있어서,
    상기 라이브러리 이름을 포함하는 라인 제거는 스택 트레이스의 라인별로 시스템 또는 개발엔진 라이브러리 이름, 클래스 이름 또는 메쏘드 이름을 확인하면서 수행하는 크래시 리포트 그룹핑 방법.
  9. 제2항에 있어서,
    상기 매칭여부 판단단계는, 애플리케이션 크래시 그룹 타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스의 상호 동일여부 판단을 포함하고, 개발엔진 크래스 그룹타입이거나 시스템 크래시 그룹타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스의 상호 유사여부 판단을 포함하는 것인 크래시 리포트 그룹핑 방법.
  10. 제9항에 있어서,
    상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스의 유사 여부는 루트 코즈 라인은 서로 동일하고, 상호 일치하는 스택 트레이스의 라인 개수의 비율이 일정 퍼센트 이상이면 유사한 것으로 판단하는 것인 크래시 리포트 그룹핑 방법.
  11. 제2항에 있어서,
    매칭이 되지 않으면, 상기 크래시 위치, 상기 예외 타입, 상기 크래시 그룹 타입, 상기 루트 코즈 라인 및 상기 추출된 정제된 스택 트레이스를 포함하는 새로운 대표 크래시 리포트로 분류하는 단계를 추가로 포함하는 크래시 리포트 그룹핑 방법.
  12. 제1항에 있어서,
    상기 플랫폼은 iOS 또는 Android 운영체제이고,
    상기 언어 계층은 Java 또는 C# 가상머신(VM) 언어계층, 또는 C 또는 C++ Native 언어계층이고,
    상기 애플리케이션 개발엔진 종류는 Unity, Unreal 또는 cocos2d이고,
    상기 크래시 위치는 Android 크래시인 경우는 Java Exception, Android Unity Native Crash, Android Native Crash 및 C# Script Exception 중 하나이고, iOS 크래시인 경우는 iOS Native Crash 및 C# Script Exception 중 하나인 것인 크래시 리포트 그룹핑 방법.
  13. 제12항에 있어서,
    상기 크래시 위치가 Android의 Android Native Crash 또는 iOS Native Crash인 경우, 라이브러리 이름을 포함하는 라인들 제거 단계 이전에 스택 트레이스의 메모리 어드레스를 해싱(hashing)하여 스택 트레이스 해시값을 할당하는 단계와, 상기 메모리 어드레스와 관련된 메쏘드로 매핑하는 심볼화(symbolication) 단계를 더 포함하는 크래시 리포트 그룹핑 방법.
  14. 제13항에 있어서,
    상기 심볼화가 실패한 경우,
    매칭 여부 판단 단계는 상기 크래시 위치, 상기 예외 타입 및 상기 스택 트레이스의 해시 값을 비교하는 것을 포함하고, 상기 스택 트레이스 라인 제거단계, 상기 정제된 스택 트레이스 추출 단계를 생략하는 크래시 리포트 그룹핑 방법.
  15. 제2항에 있어서,
    상기 크래시 위치와 예외 타입을 기준으로 상기 매칭여부를 판단하여 1차 크래시 리포트 그룹핑을 한 후, 크래시 그룹 타입, 루트 코즈 라인, 정제된 스택 트레이스를 기준으로 상기 매칭여부를 추가 판단하여 2차 크래시 리포트 그룹핑을 하는 것인 크래시 리포트 그룹핑 방법.
  16. 제1항에 있어서,
    스택 트레이스가 헤더를 포함하는 경우, 상기 제거단계는 상기 스택 트레이스에서 상기 헤더도 제거하는 것을 포함하는 것인 크래시 리포트 그룹핑 방법.
  17. 제7항에 있어서,
    상기 회복되는 스택 트레이스 라인들은 크래시 리포트들을 서로 구분하는데 유용한 라인들이고, 회복되지 못한 스택 트레이스 라인들은 크래시 리포트들 사이에 공통되는 라인들 또는 스택 트레이스 라인의 일부 정보가 누락된 라인들로서 크래시 리포트 구분에 유용하지 않은 라인들인 것인 크래시 리포트 그룹핑 방법.
  18. 제1항에 있어서,
    애플리케이션 라이브러리 이름을 포함하는 라인들의 일부를 제거하는 단계를 더 포함하는 크래시 리포트 그룹핑 방법.
  19. 제18항에 있어서,
    상기 제거되는 애플리케이션 라이브러리 이름을 포함하는 라인은 애플리케이션 개발엔진 클래스 또는 메쏘드 이름을 포함하거나, 중복된 라인이거나, 라인내 위치 정보가 없는 것인 크래시 리포트 그룹핑 방법.
  20. 제1항에 있어서,
    상기 크래시 리포트 그룹핑 방법은
    상기 스택 트레이스 라인 제거단계를 대신하여,
    상기 스택 트레이스 라인들에서 애플리케이션에 관련된 라인들의 일부 또는 전부를 추출하고,
    애플리케이션에 관련된 라인이 없는 경우, 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 추출하고,
    애플리케이션 및 애플리케이션 개발엔진에 관련된 라인이 없는 경우, 시스템에 관련된 라인들의 일부 또는 전부를 추출하는 단계를 포함하고,
    상기 정제된 스택 트레이스는 상기 추출단계를 통해 추출된 라인들을 포함하는 스택 트레이스이고,
    상기 방법은
    상기 정제된 스택 트레이스의 라인들을 기준으로 상기 크래시를 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 중 어느 하나의 크래시 그룹 타입으로 분류하는 단계를 더 포함하고,
    상기 매칭여부 판단 단계는 상기 크래시 그룹 타입을 비교하는 것을 포함하는 크래시 리포트 그룹핑 방법.
  21. 크래시 리포트 그룹핑 서버에 있어서,
    상기 서버와 통신가능한 단말기로부터 상기 단말기에 설치된 애플리케이션에 대한 크래시 리포트를 수신하는 크래시 리포트 수신부,
    상기 수신된 크래시 리포트에서 크래시가 발생한 플랫폼, 언어 계층 또는 애플리케이션 개발엔진 종류를 기준으로 크래시를 구분하는 크래시 위치(crash location)를 확인하는 크래시 위치 확인부,
    상기 수신된 크래시 리포트에 기재된 크래시의 예외 타입(exception type)을 확인하는 크래시 예외타입 확인부,
    상기 크래시 리포트의 스택 트레이스(stack trace)에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하는 스택 트레이스 라인 제거부로서, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남기는, 상기 스택 트레이스 라인 제거부,
    상기 스택 트레이스에서 상기 라인들을 제거하고 남은 정제된 스택 트레이스를 추출하는 정제된 스택 트레이스 추출부, 및
    상기 크래시 위치, 상기 예외 타입, 상기 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인(root cause line), 및 상기 추출된 정제된 스택 트레이스를 크래시 원인별 대표 크래시 리포트의 크래시 위치, 예외 타입, 루트 코즈 라인, 및 정제된 스택 트레이스와 비교하여 매칭여부를 판단하는 크래시 리포트 매칭부를 포함하고,
    제1항 내지 제20항 중 어느 하나의 항에 따른 크래시 리포트 그룹핑 방법을 수행하는 것인 크래시 리포트 그룹핑 서버.
  22. 컴퓨터 판독가능한 기록매체에 저장된 크래시 리포트 그룹핑 컴퓨터 프로그램에 있어서, 컴퓨터의 프로세서에 의해 실행될 때, 제1항 내지 제20항 중 어느 하나의 항에 따른 크래시 리포트 그룹핑 방법을 수행하는 것인 크래시 리포트 그룹핑 컴퓨터 프로그램.
PCT/KR2018/006955 2017-06-20 2018-06-20 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램 WO2018236141A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020170078195A KR101860674B1 (ko) 2017-06-20 2017-06-20 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
KR10-2017-0078195 2017-06-20

Publications (1)

Publication Number Publication Date
WO2018236141A1 true WO2018236141A1 (ko) 2018-12-27

Family

ID=62452434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/006955 WO2018236141A1 (ko) 2017-06-20 2018-06-20 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램

Country Status (2)

Country Link
KR (1) KR101860674B1 (ko)
WO (1) WO2018236141A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110489345A (zh) * 2019-08-08 2019-11-22 北京字节跳动网络技术有限公司 一种崩溃聚合方法、装置、介质和设备
CN111258803A (zh) * 2020-02-12 2020-06-09 北京字节跳动网络技术有限公司 崩溃定位方法、装置及电子设备
CN112099982A (zh) * 2020-09-08 2020-12-18 北京字节跳动网络技术有限公司 一种崩溃信息定位方法、装置、介质和电子设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112596980A (zh) * 2020-12-24 2021-04-02 上海艾融软件股份有限公司 ios性能收集方法及装置、移动终端、计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008299723A (ja) * 2007-06-01 2008-12-11 Hitachi Systems & Services Ltd プログラム検証方法、プログラム検証装置
KR20130053027A (ko) * 2011-11-14 2013-05-23 (주)네오위즈게임즈 프로그램의 비정상적 종료에 대한 데이터 제공 및 수집 방법과 그 장치
KR20140054574A (ko) * 2012-10-29 2014-05-09 에스케이플래닛 주식회사 크래시 정보 처리 시스템 및 방법과, 이를 지원하는 장치 및 단말기
KR101619691B1 (ko) * 2015-01-22 2016-05-10 주식회사 엔씨소프트 프로그램 오류 분석 방법 및 시스템
KR20160132856A (ko) * 2014-03-17 2016-11-21 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 사용자 모드 크래시 리포트를 위한 프레임워크

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008299723A (ja) * 2007-06-01 2008-12-11 Hitachi Systems & Services Ltd プログラム検証方法、プログラム検証装置
KR20130053027A (ko) * 2011-11-14 2013-05-23 (주)네오위즈게임즈 프로그램의 비정상적 종료에 대한 데이터 제공 및 수집 방법과 그 장치
KR20140054574A (ko) * 2012-10-29 2014-05-09 에스케이플래닛 주식회사 크래시 정보 처리 시스템 및 방법과, 이를 지원하는 장치 및 단말기
KR20160132856A (ko) * 2014-03-17 2016-11-21 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 사용자 모드 크래시 리포트를 위한 프레임워크
KR101619691B1 (ko) * 2015-01-22 2016-05-10 주식회사 엔씨소프트 프로그램 오류 분석 방법 및 시스템

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110489345A (zh) * 2019-08-08 2019-11-22 北京字节跳动网络技术有限公司 一种崩溃聚合方法、装置、介质和设备
CN110489345B (zh) * 2019-08-08 2023-08-25 北京字节跳动网络技术有限公司 一种崩溃聚合方法、装置、介质和设备
CN111258803A (zh) * 2020-02-12 2020-06-09 北京字节跳动网络技术有限公司 崩溃定位方法、装置及电子设备
CN111258803B (zh) * 2020-02-12 2023-03-28 北京字节跳动网络技术有限公司 崩溃定位方法、装置及电子设备
CN112099982A (zh) * 2020-09-08 2020-12-18 北京字节跳动网络技术有限公司 一种崩溃信息定位方法、装置、介质和电子设备

Also Published As

Publication number Publication date
KR101860674B1 (ko) 2018-05-23

Similar Documents

Publication Publication Date Title
WO2018236141A1 (ko) 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
WO2010062063A2 (ko) 브라우저 기반 어뷰징 방지 방법 및 시스템
WO2020233077A1 (zh) 系统服务的监控方法、装置、设备及存储介质
WO2011122724A1 (ko) 아밥 소스코드의 코드 검사를 수행하는 코드검사 수행시스템
WO2020015067A1 (zh) 数据采集方法、装置、设备及存储介质
WO2013081282A1 (en) System and method for recommending application by using keyword
WO2014035043A1 (ko) 악성 애플리케이션 진단 장치 및 방법
WO2020253112A1 (zh) 测试策略的获取方法、装置、终端及可读存储介质
WO2014044136A1 (zh) 基于分布式数据的并发处理方法、系统和计算机存储介质
WO2020218870A1 (en) Electronic apparatus and method for controlling thereof
WO2021012481A1 (zh) 系统性能监控方法、装置、设备及存储介质
CN109074448B (zh) 计算装置的安全状态与额定安全状态的偏差的检测
WO2019054613A1 (ko) 바이너리 파일에 기초하여 오픈소스 소프트웨어 패키지를 식별하는 방법 및 시스템
WO2022108318A1 (ko) 스마트 컨트랙트 코드 취약점 분석 장치 및 방법
WO2019231194A1 (ko) 메모리 오류를 검출하는 방법 및 시스템
WO2016085272A1 (ko) 소스 코드의 오류 검출에 있어서 오경보 저감 방법, 이를 위한 컴퓨터 프로그램, 그 기록매체
WO2020253125A1 (zh) 日志管理方法、装置、设备及存储介质
WO2022114689A1 (ko) 이미지 기반 악성코드 탐지 방법 및 장치와 이를 이용하는 인공지능 기반 엔드포인트 위협탐지 및 대응 시스템
KR102256894B1 (ko) 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
WO2014200201A1 (ko) 시스템 보호를 위한 파일 보안용 관리장치와 관리방법
WO2013125867A1 (ko) 컴퓨터 시스템과, 파일 및 행위 기반 복합룰 작성 시스템
WO2019245247A1 (en) Method for object management using trace identifier, apparatus for the same, computer program for the same, and recording medium storing computer program thereof
WO2018043885A1 (ko) 악성코드탐지시스템 및 악성코드 탐지 방법
WO2018080009A1 (en) Electronic apparatus for recording debugging information and control method thereof
WO2020213885A1 (en) Server and control method thereof

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: 18819604

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: 18819604

Country of ref document: EP

Kind code of ref document: A1