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

Abstract

Disclosed is a crash report grouping method according to some embodiments of the present disclosure. The method includes: receiving a crash report for an application installed in the terminal from a terminal capable of communicating with a server; identifying a crash location and an exception type of the crash in the received crash report; primary grouping of the crash report based on the crash location and the exception type; extracting a refined stack trace from a stack trace of the received crash report; and secondary grouping of the primary grouped crash report based on the refined stack trace and crash group type.

Description

Method, Server and Computer Program for Crash Report Grouping

The present invention relates to crash report grouping, and more particularly, to performing crash report grouping by analyzing a crash log of a mobile app.

Since quality control and maintenance of applications (called 'apps') are directly related to sales, app crash management is essential. In order to lower the application crash rate, it is necessary to analyze numerous crash logs and troubleshoot by identifying the cause of the crash. In order for the app manager to identify the cause of the crash and further troubleshoot, it is necessary to provide the cause of numerous crash logs and to classify and manage them efficiently. For this, crash grouping is required.

Conventionally, even though the crashes are caused by the same cause, since the device model name, OS version, and game app version are included in the report, it can be seen as different crashes, so it is difficult to troubleshoot. There are crash report grouping tools such as Crashlytics, Apteligent, and Hockey App, but they do not recognize and remove the stack trace lines related to system libraries, classes or methods, or game development engines that vary by OS version or device. Since grouping is performed by checking the coincidence of the stack trace, the degree of grouping is low, which is inefficient. In other words, several grouping tools have grouped without distinguishing whether the crash is related to the system, development engine, or game app.

Although grouping judgment was simple for server or window crashes, there is a problem in that grouping is not easy in a mobile environment due to various types of mobile devices and OSs. If grouping is difficult, it is difficult to quickly and efficiently troubleshoot because it is necessary to apply new or different trouble shooting for each crash report.

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

To this end, the present invention performs crash grouping by extracting a user logic line of a crash stack trace. In one embodiment of the present invention, the game engine or the system library is ignored, and the root cause of the crash is preferentially grouped. Compare similarities by considering variable lines in the stack trace, but exclude methods that change at different runtimes.

An embodiment of the present invention provides a crash report grouping method performed in 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 type of platform, language layer, or application development engine where the crash occurred identifying a crash location that identifies a crash based on the criteria; checking an exception type of the crash described in the received crash report; Remove system-related lines and application development engine-related lines from the stack trace of the crash report, but if there are only system-related lines in the stack trace before the removal, some of the system-related lines Or, leaving all, if there are only lines related to the application development engine in the stack trace before the removal, or only lines related to the system related lines and the application development engine, some or all of the lines related to the application development engine removing the stack trace line leaving a ; removing the lines from the stack trace and extracting the remaining refined stack trace, and the crash location, the exception type, a root cause line that is the highest line of the refined stack trace, and the extracted Provided is a crash report grouping method, which includes comparing the refined stack trace with the crash location, exception type, root cause line, and refined stack trace of the representative crash report for each crash cause to determine whether it is a match.

Another embodiment of the present invention provides a computer program stored in a computer-readable recording medium implementing 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 type of platform, language layer, or application development engine where the crash occurred a crash location check unit for checking a crash location that classifies a crash as a reference; 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 unit that removes system-related lines and application development engine-related lines from a stack trace of the crash report, and when there are only system-related lines in the stack trace before the removal, the Leave some or all of the system-related lines, and if there are only lines related to the application development engine in the stack trace before the removal or only lines related to the system-related lines and the application development engine, the application development engine the stack trace line remover leaving some or all of the associated lines; a refined stack trace extractor configured to remove the lines from the stack trace and extract the remaining refined stack trace; and a crash location, exception type, and root of the representative crash report for each crash cause using the crash location, the exception type, a root cause line that is the highest line of the refined stack trace, and the extracted refined stack trace. Provided is a crash report grouping server including a cause line and a crash report matching unit that determines whether or not a match is made by comparing it with a refined stack trace.

The present invention provides an effective grouping method for grouping the crash log of a mobile app, and in particular, crash grouping specialized for a mobile game application.

According to an embodiment of the present invention, even though the crash is caused by the same cause, the report includes the device model name, OS version, and game app version, so that the reported crash is recognized as the same crash and the same trouble is solved. shooting) can be applied.

Effective crash report grouping enables efficient crash management and quick troubleshooting. Accordingly, application maintenance costs can be reduced and the lifespan of the application can be extended.

1 is a schematic configuration 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 20 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 in detail the process of secondary crash report grouping (S320) among the operations 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 representative crash report DB 207 structure.

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

- Crash means that the computer or program itself stops while running.

- A crash report is a report that the crash report app or module catches and organizes all information about crashes that have occurred in the user terminal, and the crash log file is an example. Crash log files may contain various information about the crash, such as headers, stack traces, crash location, CPU usage, or crash capture photos.

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

- The crash exception type is described in the header or stack trace field of the crash log file, and the exception type is caught by the crash reporting module related to the terminal application, written in the log file, and sent to the server. There are two types of exception types: POSIX signal type and Exception type. A POSIX signal is a process signal used in Unix-like and POSIX compatible operating systems, and the operating system reports an exceptional state of the process. Depending on the signal type, the process receiving the signal ignores it, cannot proceed further, or stops the program. Examples of POSIX signals are SIGABRT (process abort signal), SIGBUS (access to part of an undefined memory object), SIGFPE (arithmetic operation in error), SIGILL (invalid instruction), and SIGSEGV (invalid memory reference). have. Examples of Exceptions include NullReferenceException (no object address), IndexOutOfBoundException (the specified index in the object array cannot be referenced), and IllegalStateException (the object state is not suitable for a method call).

- Crash location refers to the type of platform, language layer, or application development engine where the actual crash occurred. It can be divided into iOS/Android (operating system), Java/C# (virtual machine language), Native (hardware-friendly low-level language, language in which the operating system is implemented), and game engine types (Unity, Unreal, cocos2d, etc.). For example, there are 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, and the class and method names are detailed in the stack trace. Android Unity Native Crash is an exceptional case, and before catching the crash in the NDK, the Unity stage directly catches the crash and creates and sends a stack trace, but there is no need for a separate mapping process. In the case of Android and iOS Native Crash, it is dropped to a memory address dump file when a crash occurs, so grouping can be performed using the stack trace of the memory address before mapping to an easily identifiable class. If memory addresses are mapped to easily identifiable class and method names, meaningful method lines can be distinguished and grouped.

- A method is a function that performs a certain logic.

- Stacktrace refers to the list of method, class, and library calls at the point in time when an error occurs and before that, and consists of multiple lines.

- The crash group type is a crash type that distinguishes the highest code implementation level among the lines that are easy to troubleshoot shown in the crash stack trace. There are an application crash group, an application development engine crash group, and a system crash group. The ranking of the crash group types is highest in the order of application crash group, development engine crash group, and system crash group.

- Grouping means classifying or grouping things of the same kind.

- System library, class or method includes Device, OS, OS-SDK related library, class or method, and system library is also called System Framework.

- Root Cause means the root cause of an event.

- Symbolization is the operation of converting the stack trace into a human-readable format by mapping addresses expressed in hexadecimal numbers 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 the Android basic interface directly in addition to Android's SDK (Android Software Development Kit).

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

- A game engine is a software-based tool (framework) that provides various functions for game development, and is also called a game development engine.

- Unity is Unity's game engine that provides various platforms.

Hereinafter, an embodiment according to the present invention will be described in detail with reference to the accompanying drawings. The configuration of the present invention and the effects thereof will be clearly understood through the following detailed description.

Prior to the detailed description of the present invention, it is noted that the same components are denoted by the same reference numerals as possible even if they are shown in different drawings, and detailed descriptions of known components will be omitted if it is determined that the subject matter of the present invention may be obscured. 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 may be a game application, the application server 30 may be a game server, and the user terminal 10 may be a mobile terminal. In the case of a mobile terminal, any type of device is possible as long as it is a device capable of installing and executing a mobile device such as a smartphone or tablet PC or a game application. The user terminal 10 installs a game application and accesses the game server 30 to play a game. The game application 101 installed in the user terminal 10 may have a built-in crash reporting module 102 . The crash reporting module 102 generates a crash log file by catching a crash occurring in the application, and then performs a function to be transmitted to the crash report grouping server 20 .

The game server 30 may be constructed and operated and managed by a game development company, or a company providing a plurality of games or a publishing company may take over from the game developer and directly operate and manage the server 30 . The crash report grouping server 20 receives a crash report (eg, a crash log file) generated during a game in the user terminal 10 , analyzes the crash type, and performs grouping. The crash report grouping server 20 has a configuration distinct from the game server 30 and may be located at a game development company or a publishing company. Alternatively, unlike FIG. 1 , the crash report grouping server 20 may be configured as a part of the application server 30 .

After the grouped crash report is transmitted to the game developer for trouble shooting, 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 20 according to the present invention. The crash report receiving unit 201 receives the crash log file from the user terminal 10 and transmits it to each component of the crash report grouping server 20 . The crash location check unit 202 receives the crash log file, and refers to the crash location DB 212 for location information of the crash occurrence recorded in a separate field distinct from the field in which the header or stack trace exists among the fields in the log file. After confirming, it is sent to the crash report matching unit 206 . The crash occurrence location may be indicated by a platform, a language layer, a game engine type, or a combination thereof. In a specific example, 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, and the game application development engine type is Unity, Unreal, or cocos2d. The above crash location is Java Exception in case of Android crash, Android It may be one of Unity Native Crash, Android Native Crash, and C# Script Exception, and in case of iOS crash, it may be one of iOS Native Crash and C# Script Exception.

The crash exception type check unit 203 refers to the crash exception type DB 213, checks the crash exception type described in the header or stack trace in the crash log file, and matches the information to the crash report matching unit 206 send to

After receiving the crash log file from the crash report receiving unit 201 or the symbolizing unit 210, the stack trace line removal unit and the refined stack trace extracting unit 204 maintain only lines useful for distinguishing the crash reports from each other and maintain the remaining lines. The line is removed and a refined stack trace is extracted and sent to the crash report matching unit 206 and/or the crash group type classification unit 205 . The line removal removes the lines containing the system library, class or method name first, and then removes the lines containing the application development engine library, class or method name, but the system or development engine library name, class by line in the stack trace. Check the name or method name, and remove the line while referring to the stack trace line DB 214 . The stack trace line DB 214 stores data of library names, class names, and method names respectively related to system lines, application development engine lines, and application lines.

When lines related to the system and lines related to the application development engine are removed from the stack trace received from the crash report receiver 201, and lines related to the application are left, but only the lines related to the system exist in the stack trace before the removal leaves some or all of the lines related to the system, and if there are only lines related to the application development engine in the stack trace before the removal or only lines related to the system related lines and the application development engine, the application development Leave some or all of the lines related to the engine.

Specifically, if there is no line containing any library name in the stack trace after removing all the lines containing the system library, class or method name, the line containing the removed system library, class or method name Some or all of these are recovered and extracted as a purified stack trace. When only some lines are restored, some recovered stack trace lines are useful lines for distinguishing crash reports from each other, and the unrecovered or removed stack trace lines are lines common between crash reports or some information of the stack trace line. Lines that are not useful for classifying crash reports, such as lines that are missing, or lines that contain methods that vary by runtime. If a line containing the library name remains in the stack trace after removing all lines containing the system library, class, or method name, remove all lines containing the development engine library, class or method name and then add the library to the stack trace. Make sure there are no lines left containing the name. If a line including the library name does not exist in the stack trace, some or all of the lines including the removed development engine library, class or method name are recovered and extracted as a refined stack trace. If a line containing a library name exists in the stack trace even after all development engine related lines including the library name are removed from the stack trace, the remaining stack trace lines are extracted as a refined stack trace.

According to the above-described removal method, when there are all system-related lines, application development engine-related lines, and application-related lines in the stack trace, only application-related lines remain and are extracted as a refined stack trace. However, part of the lines including the application library name may be removed, and the line including the removed application library name is not useful for distinguishing crash reports from each other, and includes an application development engine class or method name. Lines, overlapping lines, lines common between crash reports, lines missing some information, or lines containing a method that varies from run time to run time may be applicable.

The stack trace may be distinguished from the header, but if the stack trace includes the header, the removal function may include removing the header from the stack trace as well.

It may be possible to extract the stack trace purified as follows without removing the stack trace line. That is, if there are application-related lines from the stack trace lines, some or all of them are first extracted to obtain a refined stack trace. If there is no line related to the application, check whether there are lines related to the application development engine, and if there are, some or all of them are extracted as a refined stack trace. When there are no lines related to the application and the application development engine, some or all of the remaining lines, ie, lines related to the system, may be extracted as a refined stack trace.

The crash group type classification unit 205 receives the refined stack trace lines from the stack trace line removal unit and the refined stack trace extraction unit 204, and then sets the related crash group types to the application crash group and development engine crash. Classify into any one type of group and system crash group, and send the information to the crash report matching unit 206 . Alternatively, the crash group type classification unit 205 may receive the crash log file from the crash report receiving unit 201 and may be configured to classify the highest code implementation level among lines that are easy to troubleshoot. Specifically, the rank of the crash group type is high in the order of the application crash group, the development engine crash group, and the system crash group, and the crash group type checks each related crash group while reviewing the stack trace lines for each line before the removal step. However, among the related crash groups, the top crash group can be classified as the crash group type of the corresponding log file.

According to an embodiment, the crash group type classification performed by the crash group type classification unit 205 may be performed together by the stack trace line remover and the refined stack trace extractor 204 .

The stack trace hashing unit 208, for example, when the crash location is AOS or iOS Native Crash, stack trace lines may include a memory address value, and uses a hash algorithm and uses the stack trace hashing DB ( 209), a hash key that is a fixed-length key value corresponding to stack trace lines including a memory address value may be generated.

The symbolization unit 210 refers to the symbolization DB 211 and maps them to class names and/or method names corresponding to memory address values of stack trace lines. If the symbolization fails, the stack trace line removal unit and the refined stack trace extraction unit 204 cannot perform their functions, and the hash value generated by the stack trace hashing unit 208 is returned to the crash report matching unit 206. can be utilized.

On the other hand, if the stack trace line consists of a library name, class name, and/or method name rather than a memory address value, the stack trace hashing unit 208 and the symbolizing unit 210 can perform hashing and symbolization, respectively. no, no need

The crash report matching unit 206 includes the crash location received from the crash location checking unit 202, the exception type received from the crash exception checking unit 203, and the extracted refined refined stack trace extraction unit 204 received from The stack trace, the root cause line, which is the highest line of the refined stack trace, is compared with the crash location, exception type, refined stack trace, and root cause line of the representative crash reports for each cause stored in the representative crash report DB 207 and matched. Check the representative crash report. The app code for identifying the corresponding game application can also be compared with each other and used for matching (not shown).

In addition, the crash group type received from the crash group type classification unit 205 may be used to compare and match the crash group type of the representative crash report. In the case of the application crash group type, it may be determined that the extracted refined stack trace and the refined stack trace of the representative crash report are identical to each other. In the case of the development engine crash group type or the system crash group type, it may be determined that the extracted refined stack trace and the refined stack trace of the representative crash report are similar to each other as matching. As to whether the extracted refined stack trace and the refined stack trace of the representative crash report are similar to each other, the root cause line is the same, and the ratio of the number of lines in the stack trace that matches each other is at least a certain percentage, for example, 70 % or more, it can be judged as being similar and matching.

If there is no matching representative crash report, it is classified as 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, and the representative crash report It is stored in the DB (207).

If the crash location is Andorid Native Crash or iOS Native Crash or symbolization fails in the symbolization unit 210, the crash report matching unit 206 represents the crash location, exception type, and hash value of the stack trace by referring to the representative crash report DB. Matching can be determined by comparing the crash location of the crash reports, the exception type, and the hash value of the stack trace.

The crash report matching unit 206 determines whether to match based on the crash location, exception type, and app code, performs the first crash report grouping, and then matches based on the crash group type, root cause line, and refined stack trace. Secondary crash report grouping can be performed to further determine whether or not there is. The representative crash report DB 207 is configured for each app code, and in the DB for each app code, representative crash reports with the same exception type and crash location among a plurality of representative crash reports are divided into one primary group. A plurality of primary groups may be included. Within each primary group, there are representative crash reports with the same crash group type, root cause line, refined stack trace or stack trace hash value (or these same items are related to the stack trace, so they can also be called representative stack traces) ) may be included in a plurality of secondary groups in a manner of classifying them into one secondary group. Accordingly, matching through the above-described primary and secondary crash report grouping can be effectively performed.

Table 1 below summarizes the format of the representative crash report described above. In Table 1 below, the information in the left column can be 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 (the number of stack trace lines)' is an attribute for improving the grouping speed and is not an essential characteristic in comparison for grouping.

app code
- Code by game application Group type (one of the types below)
- game crash
- Engine Crash
- system crash Crash location ( one of the examples of crash locations 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 Cause Line
- Crash Cause Line Exception type (one of the types of exception types below)
- POSIX signals
- Exception name Stacktrace (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 the crash report receiving unit 201 receives the crash report (S300), the crash location, exception type, and app code are identified (see S302 and 202 and 203 in FIG. 2), and based on this information, the crash report matching unit 206 ) performs the first crash report grouping (S304). Next, it is checked whether the crash exception type is Android Native Crash or iOS Native Crash (S306), and if it is checked as an exception type different from this, system-related lines in the stack trace are checked line by line, is removed (S308). After step S308, it is checked whether the stack trace line remains (S310), and if the stack trace line remains, the application development engine-related line is removed from the stack trace (S312), and when it is confirmed that there is no remaining stack trace line in step S310, the removed A part of the system-related stack trace line is recovered (S322). It is checked whether the stack trace line remains after removal of the stack trace line through step S312 (S314), and if not, part of the removed application development engine related lines is restored (S324). The determination criteria for some lines recovered in steps S322 and S324 and some lines removed without recovery are the same as described above with respect to the stack trace line remover and the refined stack trace extractor 204 . Depending on the implementation, the entire removed line may be recovered without selectively recovering in steps S322 and S324. The stack trace lines remaining after step 314, that is, application-related stack trace lines, or system-related lines or development engine-related lines recovered through steps 322 and 324, are extracted as a refined stack trace, and the refined stack trace The uppermost line, that is, the frontmost line in , is extracted as the root cause line (S316). Since the extracted refined stack trace is related to any one of a system, an application development engine, and an application, a crash group type is classified based on the relevance (S318). Based on the extracted refined stack trace, root cause line, and crash group type, a matching crash report subgroup (secondary group) is identified among a plurality of subgroups in the previously classified crash report group (S320). If the exception type is Android Native Crash or iOS Native Crash in the aforementioned step S306, the stack trace is hashed (S326) and system-related lines are removed through symbolization (S328, S330) (S308). Steps S326 and S328 are possible even if the order is changed. If symbolization is not possible in S328, secondary crash report grouping (S320) may be performed using the stack trace hash value generated in step S326.

FIG. 4 is a flowchart illustrating in detail the process of secondary crash report grouping (S320) among the operations of the crash report grouping server according to FIG. 3B. First, it is checked whether the stack trace line is defined as a hash value (S400), and if not, it is checked whether the extracted refined stack trace is an application crash group type (S402). In the case of the application crash group type, the extracted refined stack trace is stored in the representative crash report DB 207 and the refined stack trace of multiple representative crash reports in the same primary crash report group ('representative stack trace') ) to determine whether there are identical stack traces with each other (S404). If there is the same representative stack trace, it is matched with the corresponding representative stack trace (S406). If there is no identical representative stack trace, the extracted refined stack trace is used as a new representative stack trace and the same primary stored in the representative crash report DB 207 It is added to the crash report group (S412).

If it is not the application crash group type in step S402, the extracted refined stack trace is compared with a plurality of representative stack traces in the same primary group stored in the representative crash report DB 207, respectively, so that the root cause line is the same and (S408) check whether the number of mutually matching stack trace lines is, for example, 70% or more (S410), and match the representative stack trace that satisfies the two conditions (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 stored in the representative crash report DB 207 (S412).

If the received stack trace line is defined as a hash value in step S400, the same representative stack trace is obtained by comparing the hash value of the received stack trace with the hash values of a plurality of representative stack traces in the same primary group. Confirm (S414). If there is an existing representative stack trace with the same hash value, it is matched with this representative crash report (S406), and if there is no existing representative stack trace with the same hash value, the representative crash report DB 207 is classified as a new representative stack trace It is added to the group (S412).

The following describes the present invention through the header of the crash log file and the stack trace sample. For convenience of explanation, serial numbers are assigned to the log file lines.

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

The app code is 'mherosgb' shown in line 3, which can be checked by referring to the app code verification unit and the app code DB, which are omitted. The field of the crash log file showing the crash location is not shown in the sample above, but it is assumed that the raw data "Crash location: Android Unity Native Crash" has been confirmed. Since the crash location is received with a separate field title called Crash location, it is easy to check and can be confirmed by referring to the DB 212. It can exist in a field separate from the stack trace/header, can be delivered in the form And for convenience of description, the specification of the components of FIG. 2 that performs each of the following functions is mentioned only at the minimum necessary for explanation in this sample description, and the order of the description will be described so as to match the flowcharts of FIGS. 3 to 4 as much as possible. Lines 1 to 7 correspond to headers, and the crash exception type check unit 203 can check SIGSEGV, which is one of the POSIX signal types, among the crash exception types recorded in the crash exception type DB 213 . SIGSEGV is an exception type that means invalid memory reference. Primary crash report grouping is possible with these information.

Next, since the crash location is Android Unity Native Crash, proceed to the step of removing the stack trace line. In the stack trace consisting of lines 8 to 38, the stack trace line removing unit and the refined stack trace extracting unit 204 go down sequentially from line 8 and refer to the stack trace line DB 214 to remove lines related to the system. . Line 8 corresponds to the system-related stack trace line and is removed because libc is the system library name, kill is the system-related method, and 12 is the location. No system related lines are found from line 9 to line 38. Since a number of stack trace lines (lines 9 to 38) remain after removing the system-related lines, the application development engine-related lines are removed next. In line 9, libmono means the name of the game development engine library, 002ad36c means the address of the method, and Native Method means the method implemented in the native language, so it falls under the game development engine line and is removed. For the same or similar reasons, lines 10 to 16 and lines 21 to 38 are sequentially removed while referring to the stack trace line DB 209 . Even after the game development engine line is removed, stack trace lines 17 to 20 remain. These lines are application related lines. You can extract these lines as a refined stack trace, and take the top line 17 as the root cause line. However, for more effective grouping, the stack trace line remover and the refined stack trace extractor 204 may be set to additionally delete lines without location information among the remaining application-related lines. In such a case, line 17 without location information among 17 to 20 may be further deleted, lines 18 to 20 may be extracted as a refined stack trace, and line 18 may be extracted as a root cause line. And, since the extracted and refined stack traces are game (application) related trace lines, the crash group type is classified as a game (application) group type.

A refined stack trace that is not represented as a hash value was extracted, and since it is a game crash group type, the extracted refined stack trace is combined with the representative stack trace of several subgroups in the primary grouped group in the representative crash report DB 207, respectively. While comparing, the same representative stack trace is searched for and matched. If not, a new subgroup is created in the primary group in the representative crash report DB 207 and stored as a new representative stack trace.

This refined crash report will be used to infer clues for troubleshooting, especially by looking at root cause lines and stack traces. In the case of Sample 1 above, it can be inferred that the GetSummoner method, which obtains an object called Summoner, was executed among the game logic implemented by the game developer, and the logic referring to the wrong memory was executed, resulting in a crash.

[Sample 2]

The sample below is an excerpt of a part of the stack trace of the iOS Native Crash log after the symbolization process.

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, since there is no game engine library name and only the game library name exists, the game engine-related stack trace line can be distinguished through the game engine-related class name or method name. The library name of each stack trace line in Sample 2 above is Full2016, and this library name is commonly used by the game library and the game engine library. Since they are related, all stack trace lines in Sample 2 can be understood as game engine related lines. This determination is made possible based on information such as the iOS game library name stored in the stack trace line DB 214 .

[Sample 3]

Assuming that the crash location is confirmed by the iOS Native Crash log in another field of the crash log file, the stack trace and header are extracted 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' displayed in the identifier field, but you can check it by referring to the app code verification unit and the app code DB that are omitted.

Since the exception type is described as SIGABRT in the header of the above log file, the primary crash report grouping can be performed together with the above-described 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 check whether it matches the representative stack trace. The stack trace hash value is a data value of a fixed length created through a hash algorithm. The hash value below is a value created by using the MD5 algorithm, which is one of the hash algorithms, for lines 0 to 12 of the log file above.

6ea0ca5491f32bb8db110d15b12ae66d

Of course, it is possible to compare the sameness and similarity between crash reports by using the lines containing the memory addresses from line 0 to line 12 without a hash value as it is, but in such a case, the efficiency will be greatly reduced.

A stack trace successfully symbolized by referring to the symbol 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)

The stack trace line DB 214 may include information on lines according to each crash group type, information on general-purpose lines identified in most stack traces, information on methods that vary for each runtime, and the like. While referring to the stack trace line DB 214 , it is checked whether the lines 0 to 12 are system related lines in order. As a result, since all of the system-related lines are system-related, lines 0 to 12 are all deleted. Since there is no remaining line after the deletion, these system-related lines must be recovered. When recovering lines 0, 1, and 12, referring to the stack trace line DB 214, since they are included in most stack traces, only lines 2 to 11 may be recovered without recovery. These lines 2 to 11 are extracted as refined stack traces, and among them, line 2, which is the highest line, is extracted as a root cause line. And, since the crash group type is classified as a system type, the secondary crash report grouping is performed with these information. Among the representative stack traces of subgroups in the primary classified group, a representative stack trace having the same crash group type and the extracted root cause line and having 7 or more lines 2 to 11 identical, that is, 70% or more, is searched. If there is a matching representative stack trace through the search, the refined stack trace extracted to the corresponding subgroup is stored in the DB 207. If there is no matching representative stack trace, the representative stack of a new subgroup in the primary classified group It is stored in the DB 207 as a trace.

5 is a schematic diagram illustrating the structure of the primary and secondary crash report grouping and the representative crash report DB 207 described above. Here, the primary grouping is classified only as a crash exception type for convenience 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, subgroups D, E, and F are included in the IndexOutBoundException group, and each subgroup includes a representative stack trace. When a new crash log file that needs to be grouped is received, it is first classified into one of the above primary groups with information such as crash location, exception type, and app code, and then extracted as information such as refined stack trace and crash group type. The second classification is carried out.

The crash report grouping according to the embodiment of the present invention and the grouping result of Apteligent were compared. Raven for Naver was used for the mobile game app, and the number of log files used for each crash type was 80 Java Exception logs, 200 NDK Native crash logs, and 200 iOS Native crash logs. A total of 480 log files were used for testing. became As a result of crash report grouping, Apteligent classified 406 crash groups, whereas the grouping method according to the embodiment of the present invention classified 282 crash groups. That is, the number of groups decreased by about 30% compared to Apteligent.

The exemplary methods according to the present invention include program instructions executed by a processor, a software module, a microcode, a computer program product recorded on a computer-readable recording medium (including all devices having an information processing function), It can be implemented in a variety of ways, such as applications, logic circuits, application specific 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 device. In addition, the computer-readable recording medium is distributed in a computer system connected through a network, so that the computer-readable code can be stored and executed in a distributed manner.

The above description is merely illustrative of the present invention, and various modifications will be possible without departing from the technical spirit of the present invention by those skilled in the art to which the present invention pertains.

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 by the following claims, and all technologies within the scope equivalent thereto should be construed as being included in the scope of the present invention. And, it will be understood that the implementation of the invention is possible even if the order of some steps described in the claims of the present invention is reversed.

10 user terminal
20 Crash Report Grouping Server
30 application server
201 crash report receiver
202 Crash Locator
203 Crash Exception Type Checker
204 Stack trace line removal part / Refined stack trace extraction part
205 crash group type classification section
206 crash report matching unit
207 Representative crash report DB
208 Stack Trace Hashing Unit
210 Symbolizer

Claims (18)

A crash report grouping method performed on a server, comprising:
receiving a crash report for an application installed in the terminal from a terminal capable of communicating with the server;
identifying a crash location and an exception type of the crash in the received crash report;
primary grouping of the crash report based on the crash location and the exception type;
extracting a refined stack trace from a stack trace of the received crash report; and
secondary grouping of the primary grouped crash report based on the refined stack trace and the crash group type;
Including,
The crash report for the application is a crash log file generated by a crash reporting module installed in the application,
The exception type can be checked in the header or stack trace of the crash log file,
The crash location can be confirmed in a separate field in the crash log file that is distinct from the header or stack trace,
How to group crash reports. The method of claim 1,
Extracting a refined stack trace from the stack trace of the received crash report comprises:
extracting a refined stack trace by removing lines related to the system and lines related to the application development engine from the stack trace of the received crash report;
Containing,
How to group crash reports. The method of claim 2,
Extracting a refined stack trace by removing lines related to the system and lines related to the application development engine from the stack trace of the received crash report,
Remove system-related lines and application development engine-related lines from the stack trace of the crash report, but if there are only system-related lines in the stack trace before the removal, some or all of the system-related lines are left , leaving some or all of the lines related to the application development engine when there are only lines related to the application development engine or only lines related to the system and lines related to the application development engine in the stack trace before the removal ;
Containing,
How to group crash reports. The method of claim 2,
Classifying the crash into any one of an application crash group, a development engine crash group, and a system crash group type based on the refined stack trace lines,
Crash report grouping method comprising comparing the crash group type in the secondary grouping step. The method of claim 1,
The secondary grouping of the primary grouped crash report based on the refined stack trace and the crash group type comprises:
The crash location, the exception type, the root cause line, which is the highest line of the refined stack trace, and the extracted refined stack trace are the crash location, exception type, and root cause line of the representative crash report for each crash cause. , and comparing with the refined stack trace and performing the secondary grouping according to whether or not they match;
Containing,
How to group crash reports. delete The method of claim 4,
The step of removing the stack trace line and the step of classifying the crash group type include:
If there is no line containing any library name in the stack trace after removing all lines containing the system library, class or method name, the group type of the crash is classified as a system crash group, and the removed system library, class or recovering some of the lines containing the method name;
If a line containing the library name remains in the stack trace after removing all the lines containing the system library, class, or method name, remove all lines containing the development engine library, class or method name, and then display the library name in the stack trace. checking whether a line containing
If there is no line containing the library name in the stack trace after removing all lines including the development engine library, class or method name, the crash group type is classified as a development engine crash group, and the removed development engine library, class or recovering some of the lines containing the method name;
After removing all lines containing the development engine library, class or method name, if a line containing the library name exists in the stack trace, classifying the crash group type as an application crash group.
How to group crash reports. The method of claim 4,
The secondary grouping includes determining whether the extracted refined stack trace and the refined stack trace of the representative crash report for each crash cause are the same in the case of an application crash group type, and a development engine crash group type or system In the case of the crash group type, the crash report grouping method includes determining whether the extracted refined stack trace and the refined stack trace of the representative crash report are similar to each other. The method of claim 8,
Whether the extracted refined stack trace and the refined stack trace of the representative crash report are similar is determined to be similar if the root cause line is the same and the ratio of the number of lines in the stack trace that matches each other is a certain percentage or more How to group crash reports. The method of claim 4,
If there is no match, classifying into a new representative crash report including the crash location, the exception type, the crash group type, the root cause line that is the highest line of the refined stack trace, and the extracted refined stack trace. How to group crash reports with additional inclusions. The method of claim 2,
When the crash location is Android Native Crash or iOS Native Crash of Android, hashing a memory address of a stack trace before removing lines including a library name to allocate a stack trace hash value; A method for grouping crash reports, further comprising a symbolization step of mapping to an address-related method. The method of claim 11,
If the symbolization fails,
The secondary grouping includes comparing the crash location, the exception type, and a hash value of the stack trace, and omitting the steps of removing lines of the stack trace and extracting the refined stack trace How to group crash reports. The method of claim 4,
After determining whether a match is made based on the crash location and the exception type, the first crash report grouping is performed, and the second crash report grouping is performed by further determining whether the match is based on the crash group type, root cause line, and refined stack trace. How to group crash reports. The method of claim 1,
The method of grouping crash reports further comprising removing some of the lines containing the application library name. The method of claim 14,
The line containing the removed application library name includes an application development engine class or method name, a duplicate line, or a crash report grouping method that does not have location information in the line. The method of claim 2,
The crash report grouping method is,
Instead of removing the lines of the stack trace,
extract some or all of the lines related to the application from the lines of the stack trace;
If there is no line related to the application, some or all of the lines related to the application development engine are extracted,
If there is no line related to the application and the application development engine, comprising the step of extracting some or all of the lines related to the system,
The refined stack trace is a stack trace including lines extracted through the extracting step,
The above method,
Classifying the crash into any one of an application crash group, a development engine crash group, and a system crash group type based on the lines of the refined stack trace,
The secondary grouping includes comparing the crash group types. In the 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;
a crash location check unit for checking a crash location in the received crash report;
a crash exception type checking unit for checking an exception type of the crash described in the received crash report;
A refined stack trace extractor for extracting a refined stack trace from the stack trace of the received crash report, and
a crash report matching unit that determines whether a match is made based on the crash location, the exception type, and the refined stack trace;
Including,
The crash report for the application is a crash log file generated by a crash reporting module installed in the application,
The exception type can be checked in the header or stack trace of the crash log file,
The crash location can be confirmed in a separate field in the crash log file that is distinct from the header or stack trace,
Crash Report Grouping Server. A crash report grouping computer program stored in a computer readable recording medium, when executed by a processor of a computer, the crash report grouping method according to any one of claims 1 to 5, 7 to 17 A crash report grouping computer program that performs

Images