KR101860674B1 - Method, Server and Computer Program for Crash Report Grouping - Google Patents

Abstract

According to one embodiment of the present invention, proposed is a crash report grouping method suitable for a crash report of a mobile application. The grouping method comprises the steps of: receiving a crash report for an application installed in a terminal from the terminal capable of communicating with a server; confirming a crash location for distinguishing a crash based on a platform, language hierarchy, or a type of application development engine where the crash occurs in the received crash report; confirming an exception type of the crash stated in the received crash report; removing stack trace lines; extracting a refined stack trace left after removing the lines in the stack trace; and comparing the crash location, the exception type, a root cause line, which is the highest line of the refined stack trace, and the extracted refined stack trace with a crash location, an exception type, a root cause line, and a refined stack trace of a representative crash report by reason of the crash and determining whether they match.

Description

A method and a computer program for crash report grouping,

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. 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.

Conventionally, despite the fact that it is a crash due to the same cause, since the report includes the device model name, the OS version, and the game app version, it can be seen as a different crash, which makes trouble shooting difficult. There are 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.

However, in the mobile environment, there is a problem that grouping is difficult because of various types of mobile devices and OS such as crash grouping. If grouping is difficult, trouble shooting should be applied differently or differently for each crash report, so that quick and efficient trouble shooting is difficult.

According to an embodiment of the present invention, a crash report grouping method suitable for a crash report of a mobile application is presented.

To this end, the present invention extracts user logic lines of the crash stack trace and performs crash grouping. In an embodiment of the present invention, 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.

According to an embodiment of the present invention, there is provided 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 of the refined stack trace, And comparing the refined stack trace with a crash location, an exception type, a root cause line, and a refined stack trace of the star representative crash report as a cause of the crash.

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 a processor for determining the crash location, the exception type, the root cause line being the top line of the refined stack trace, and the extracted refined stack trace as the crash location, exception type, And a crash report matching unit for determining whether or not matching is performed with respect to the comparison result, the causal line, and the refined stack trace.

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.

According to an embodiment of the present invention, even if a crash is caused by the same cause, 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.

Effective crash report management and quick troubleshooting are possible through effective crash report grouping. This reduces application maintenance costs and increases application life.

1 is a schematic block diagram of a system for performing crash report grouping according to the present invention.
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.
5 is a schematic diagram for explaining the primary and secondary crash report grouping and the typical crash report DB 207 structure.

The terms used in the present specification are defined as follows, but may also include meanings commonly used in the art within the scope of the present invention.

- 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.

- Exception means an unexpected error that may occur during program execution.

- The crash type is listed in the header or stack trace field of the crash log file. The exception type is written to the log file after the crash reporting module associated with the terminal application catches it and sent to the server. There are two types of exception types: POSIX signal types and Exception types. POSIX signals 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. Examples of 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. Examples of 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. There are application crash groups, application development engine crash groups, and system crash groups. 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).

- Native Crash Among the crashes that occurred during the execution of the program, it was a catch that was caught at the native terminal of the terminal OS, not the application terminal such as Java or C # Script.

- 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.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. The configuration of the present invention and the operation and effect thereof will be clearly understood through the following detailed description.

Before describing the present invention in detail, the same components are denoted by the same reference symbols as possible even if they are displayed on different drawings. In the case where it is judged that the gist of the present invention may be blurred to a known configuration, do.

1 is a schematic configuration diagram of a system for performing crash report grouping according to the present invention and may include a user terminal 10, a crash report grouping server 20, an application server 30 and a network 40 . The user terminal 10 refers to a terminal possessed by an application user. The network may be a wired or wireless network. Hereinafter, as an example, the application 101 is a game application, the application server 30 is a game server, and the user terminal 10 may be a mobile terminal. In the case of 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.

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).

2 is an internal configuration diagram of an example of the crash report grouping server 40 according to the present invention. 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. In a specific example, the platform is an iOS or an Android operating system, and the language layer is a Java or C # virtual machine (VM) language layer, or a C or C ++ native language layer, and 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 >

After receiving the crash log file from the crash report receiving unit 201 or from the symbolizing unit 210, 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.

In the stack trace received from the crash report receiving unit 201, 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.

Specifically, if there is no line containing any library name in the stack trace after removing all of the lines including the system library, class, or method name, 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. If all lines containing the system library, class, or method name are removed and there is a line containing the library name in the stack trace, remove all lines containing the development engine library, class, or method name, Make sure there is a line containing the name. If there is no line containing the library name in the stack trace, some or all of the lines containing the removed development engine library, class or method name are recovered and extracted as a refined stack trace. If a line containing the library name exists in the stack trace even after removing all development engine related lines containing the library name in the stack trace, the remaining stack trace lines are extracted into the refined stack trace.

According to the above elimination method, when there are lines related to the system, lines related to the application development engine, and lines related to the application in the stack trace, only the lines related to the application are extracted and extracted into the refined stack trace. However, some of the lines containing the application library name may be removed, such lines containing the application library name being removed are not useful for distinguishing the crash reports from each other, including the application development engine class or method name Lines, lines that are overlapped with each other, lines that are common between crash reports, lines that are missing some information, or a method that varies from runtime to run.

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. [ Alternatively, 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. Specifically, 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 However, 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 according to the embodiment 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.

On the other hand, when the stack trace line is composed of a library name, a class name, and / or a method name, rather than a memory address value, 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).

In addition, 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. In the case of 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. In the case of 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.

If there is no representative crush report to be matched, it is classified into a new representative crush report including the crush location, the exception type, the crash group type, the root cause line, and the extracted refined stack trace, And stores it in the DB 207.

In the case where the symbolization by the Andorid Native Crash or the iOS Native Crash or the symbolization unit 210 fails, 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. Within each primary group, 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. Among the information displayed in the right column, the number of lines (number of stack trace lines) is an attribute for improving the grouping speed, and is not an essential feature in comparison for grouping.

App code
- Game application-specific code Group type (one of the following types)
- Game Crash
- engine crash
- System crash Crash location ( one example of a crash location below)
- Android Java Exception
- Android Unity Native Crash
- Android Native Crash
- Android C # Script Exception
- iOS Native Crash
- iOS C # Script Exception Number of lines
- Number of stack trace lines Root causal line
- Crash Cause Lines Exception type (one of the types of exception types below)
- 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. 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). Next, it is checked whether 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). If the stack trace line remains, 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).

If the exception type is the Android Native Crash or iOS Native Crash in step S306, 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. First, it is confirmed whether 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). In the case of an application crash group type, 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). If there is no identical representative stack trace, 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).

If the type of application is not an application crash group type in step S402, 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).

If the stack trace line received in step S400 is defined as a hash value, 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 following describes the present invention through the header of the crash log file and the stack trace sample. For the sake of convenience, the log file line is serialized.

[Sample 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.0003bbb (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)

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 and can be stored in memory &Lt; / RTI &gt; 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. 3 to 4 as much as possible. Lines 1 to 7 correspond to the header. 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.

Next, since the crash location is Android Unity Native Crash, proceed to remove the stack trace line. In the stack trace consisting of lines 8 to 38, 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. In such a case, it is possible to further delete line 17 without position information among 17 to 20, extract lines 18 to 20 into a purified stack trace, and extract line 18 as a root causal line. And, since the extracted refined stack trace is game (application) related trace lines, the crash group type is classified into a game (application) group type.

Since the refined stack trace that is not represented by the hash value has been extracted and is the game crash group type, 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. In the case of sample 1 above, it can be inferred that 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.

[Sample 2]

The sample below is an excerpt of some of the stack traces in the iOS Native Crash log after being symbolized.

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)

In the case of iOS, 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) and 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.

[Sample 3]

Assuming that the crash location has been verified in the iOS Native Crash log in another field of the crash log file, the following is an excerpt of the stack trace and header from the crash log file.

*** 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: ??? [One]

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

In the above log file, 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.

Since the exception type is described as SIGABRT in the header of the above log file, primary crash report grouping can be performed together with the above-mentioned crash location information.

Meanwhile, 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.

6ea0ca5491f32bb8db110d15b12ae66d

Of course, you could compare the similarity between crash reports using the line containing memory addresses from line 0 to line 12 without hash values, but in such a case, efficiency would be greatly reduced.

The stack trace successfully symbolized with reference to the symbolization DB 211 is as follows.

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)

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.

5 is a schematic diagram for explaining the above-described primary and secondary crash report grouping and the typical crash report DB 207 structure. Here, 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. For example, the IndexOutBoundException group contains subgroups D, E, and F, and each subgroup contains representative stack traces. 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. In addition, 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.

The foregoing description is merely illustrative of the present invention, and various modifications may be made by those skilled in the art without departing from the spirit of the present invention.

Accordingly, the embodiments disclosed in the specification of the present invention are not intended to limit the present invention. The scope of the present invention should be construed according to the following claims, and all the techniques within the scope of equivalents should be construed as being included in the scope of the present invention. It will be appreciated that the order of some of the steps described in the claims of the present invention may be implemented by changing the order of the steps.

10 User terminal
20 Crash Report Grouping Server
30 application server
201 Crash Report Receiver
202 Crash Position Verification Unit
203 Crash Exception Type Identification Unit
204 stack trace line removing / refining stack trace extracting unit
205 Crash group type classification unit
206 crash report matching unit
207 Representative Crash Report DB
208 stack trace hashing section
210 symbolizing unit

Claims (22)

A crash report grouping method performed by a server,
Receiving a crash report for an application installed in the terminal from a terminal capable of communicating with the server,
The platform in which the crash occurred, the language layer, or the type of application development engine in the received crash report Identifying a crash location that distinguishes the crash based on the crash location,
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 from the stack trace and extracting the remaining refined stack traces, and
The root cause line being the top line of the refined stack trace, and the extracted refined stack trace as the crash location, exception type, exception code, Line, and refined stack traces to determine whether to match
And a crash report grouping method. The method according to claim 1,
Further comprising classifying the crash into a crash group type of either an application crash group, a development engine crash group, or a system crash group based on the refined stack trace lines,
And comparing the crash group types in the matching determination step. The method according to claim 1,
Wherein the application is a mobile game application. The method according to claim 1,
The crash report for the application is a crash log file generated by the crash reporting module installed in the application,
The exception type can be identified in the header or stack trace of the crash log file,
Wherein the crash location is identifiable in a separate field in the crash log file distinct from the header or stack trace. The method according to claim 1,
Wherein said removing step removes lines containing an application development engine library, class or method name after eliminating lines containing system libraries, classes or method names. 3. The method of claim 2,
Wherein the ranking of the crash group type is high in the order of an application crash group, a development engine crash group, and a system crash group, and the crash group type is classified into a top crash group in the pre-removal step. 3. The method of claim 2,
The stack trace line removal step and the crash group type classification step
If none of the lines containing the system library, class, or method name are removed and there is no line containing a library name in the stack trace, then the group type of the crash is classified as a system crash group, Or method names,
If all lines containing the system library, class, or method name are removed and there is a line containing the library name in the stack trace, remove all lines containing the development engine library, class, or method name, , &Lt; / RTI &gt; confirming whether a line including &
If there is no line containing the library name in the stack trace after removing all lines containing the development engine library, class, or method name, classify the crash group type into a development engine crash group, Or method names,
Classifying the crash group type into an application crash group if there is a line containing the library name in the stack trace after removing all lines containing the development engine library, class or method name
Crash Report Grouping Method. 8. The method of claim 7,
Wherein removing the line including the library name is performed while checking the system or development engine library name, class name, or method name for each line of the stack trace. 3. The method of claim 2,
Determining whether the extracted stack trace is identical to the refined stack trace of the representative crash report if the type of the application crash group is an application crash group type; The determination of the similarity between the extracted refined stack trace and the refined stack trace of the representative crash report. 10. The method of claim 9,
Wherein the similarity of the extracted refined stack trace and the refined stack trace of the representative crash report is determined to be similar if the ratio of the number of lines of mutually matching stack traces is equal to or greater than a certain percentage, Crash Report Grouping Method. 3. The method of claim 2,
If not, classification into a new representative crash report including the crash location, the exception type, the crash group type, the root cause line, and the extracted refined stack trace. . The method according to claim 1,
The platform is an iOS or 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 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 Native Crash and C # Script Exception for iOS Crash. 13. The method of claim 12,
Assigning a stack trace hash value by hashing the memory address of the stack trace prior to the step of removing the lines containing the library name if the crash location is Android Native Crash or iOS Native Crash of Android; The method further comprising: a symbolization step of mapping to a method associated with the address. 14. The method of claim 13,
If the symbolization fails,
Wherein the step of determining matching includes comparing the crash location, the exception type, and the hash value of the stack trace, and omitting the stack trace line removing step and the refined stack trace extracting step. 3. The method of claim 2,
The first crash report grouping is performed on the basis of the crash position and the exception type, and the first crash report grouping is performed to determine whether the matching is based on the crash group type, the root cause line, and the refined stack trace, Wherein the grouping of the crash report groups is performed. The method according to claim 1,
And if the stack trace includes a header, said removing step includes removing said header from said stack trace. 8. The method of claim 7,
The recovered stack trace lines are useful for distinguishing crash reports from each other, and the unrecovered stack trace lines are lines for common use between crash reports or lines for missing some information of a stack trace line. Wherein the plurality of lines are not lines. The method according to claim 1,
Further comprising removing a portion of lines including an application library name. 19. The method of claim 18,
Wherein the line containing the application library name to be removed comprises an application development engine class or method name, is a duplicate line, or has no location information in the line. The method according to claim 1,
The crash report grouping method
In place of the stack trace line removal step,
Extract some or all of the lines associated with the application in the stack trace lines,
If there are no lines associated with the application, some or all of the lines associated with the application development engine are extracted,
If there is no line associated with the application and the application development engine, extracting some or all of the lines associated with the system,
Wherein the refined stack trace is a stack trace comprising lines extracted through the extracting step,
The method
Further comprising classifying the crash into a crash group type of one of an application crash group, a development engine crash group, and a system crash group based on the lines of the refined stack trace,
Wherein the determining whether the matching is to include comparing the crash group type. In a crash report grouping server,
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,
The platform in which the crash occurred, the language layer, or the type of application development engine in the received crash report 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 a 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, which leaves 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 root cause line being the top line of the refined stack trace, and the extracted refined stack trace as the crash location, exception type, exception code, Line, and a refined stack trace,
A crash report grouping method according to any one of claims 1 to 20. A crash report grouping computer program stored on a computer readable recording medium, the crash report grouping computer program being executable by a processor of a computer to perform a crash report grouping method according to any one of claims 1 to 20, program.

Images