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

Abstract

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

Description

크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램{Method, Server and Computer Program for Crash Report Grouping}

본 발명은 크래시 리포트 그룹핑에 관한 것으로, 더욱 구체적으로는 모바일 앱의 크래시 로그를 분석하여 크래시 리포트 그룹핑을 수행하는 것에 관한 것이다.

애플리케이션('앱'이라고 불리움)의 품질관리 및 유지보수는 매출과 직결되므로 앱 크래시 관리는 필수적이다. 애플리케이션 크래시 비율을 떨어뜨리기 위하여 수많은 크래시 로그들을 분석하고 발생 원인을 파악하여 트러블 슈팅을 해야한다. 앱 관리자가 크래시 원인을 파악하고, 나아가 트러블 슈팅을 위해서는 수많은 크래시 로그의 원인을 제공받고 분류 및 관리가 효율적으로 이루어져야 한다. 이를 위하여 크래시 그룹핑을 필요로 한다.

종래에는 동일한 원인에 따른 크래시임에도 불구하고, 리포트에 디바이스 모델명, OS 버젼, 게임앱 버젼이 포함되므로, 서로 다른 크래시로 보일 수 있으므로, 트러블 슈팅에 어려움이 있었다. Crashlytics, Apteligent, Hockey App 등의 크래시 리포트 그룹핑 툴이 있으나, 이들은 OS 버젼이나 기기마다 달라지는 시스템 라이브러리, 클래스 또는 메쏘드, 또는 게임 개발 엔진관련 스택 트레이스 라인을 인지하지 않고 이들을 제거하지 않은 상태에서 크래시 리포트의 스택 트레이스의 일치 검사를 통하여 그룹핑하므로, 그룹핑의 정도가 낮아 비효율적이다. 즉, 여러 그룹핑 툴은 크래시가 시스템, 개발엔진, 또는 게임앱에 관한 것인지 구별하지 않고 그룹핑을 해왔다.

서버나 윈도우 크래시는 그룹핑 판단이 간단하였으나, 모바일 환경에서는 크래시 그룹핑이 다양한 모바일 기기 및 OS의 종류 등의 이유로 그룹핑이 쉽지 않은 문제점이 있다. 그룹핑이 어려우면 크래시 리포트별로 트러블 슈팅을 새롭게 또는 다르게 적용하여야 하므로 신속하고 효율적인 트러블 슈팅이 어려웠다.

본 발명의 일실시예에 따르면, 모바일 앱의 크래시 리포트에 적합한 크래시 리포트 그룹핑 방법을 제시한다.

이를 위해 본 발명은 크래시 스택 트레이스의 사용자 로직 라인을 추출하여 크래시 그룹핑을 행한다. 본 발명의 일 실시예에서는 게임 엔진이나 시스템 라이브러리를 무시하고, 크래시의 루트 코즈(root cause)를 우선적으로 그룹핑한다. 스택 트레이스의 가변적인 라인을 고려하여 유사성을 비교하되, 런타임마다 달라지는 메소드(method)는 제외한다.

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

본 발명의 또 다른 일실시예는 위 크래시 리포트 그룹핑 방법을 구현하는 컴퓨터 판독가능한 기록매체에 저장된 컴퓨터 프로그램을 제공한다.

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

본 발명은 모바일 앱의 크래시 로그를 그룹핑하는데 효과적인 그룹핑 방법을 제공하며, 특히 모바일 게임 애플리케이션에 특화된 크래시 그룹핑이다.

본 발명의 일 실시예에 따르면, 실제로는 같은 원인에 따른 크래시임에도 불구하고 리포트에 디바이스 모델명, OS 버젼, 게임앱 버젼이 포함되어 다른 크래시인 것처럼 리포트되었던 것을 동일한 크래시로 인식하여 동일한 트러블 슈팅(trouble shooting)을 적용할 수 있다.

효과적인 크래시 리포트 그룹핑을 통하여 효율적인 크래시 관리와 빠른 트러블 슈팅이 가능하다. 이에 따라, 애플리케이션 유지보수 비용이 절감되고 애플리케이션의 수명을 늘릴 수 있다.

도 1은 본 발명에 따른 크래시 리포트 그룹핑을 수행하는 시스템의 개략적인 구성도이다.
도 2는 본 발명에 따른 크래시 리포트 그룹핑 서버(40)의 일례의 내부 구성도이다.
도 3a 및 3b는 본 발명의 일실시예에 따른 크래시 리포트 그룹핑 서버의 처리 과정을 나타낸 순서도이다.
도 4는 도 3b에 따른 크래시 리포트 그룹핑 서버의 동작 중에서 2차 크래시 리포트 그룹핑(S320) 과정을 상세히 설명하는 순서도이다.
도 5는 1차 및 2차 크래시 리포트 그룹핑과, 대표 크래시 리포트 DB(207) 구조를 설명하는 도식도이다.

본 명세서에서 사용되는 용어는 다음과 같이 정의하되, 본 발명에 부합하는 범위 내에서 본 기술 분야에서 통용되는 의미도 포함할 수 있다.

- 크래시(Crash)는 컴퓨터 또는 프로그램 자체가 실행 도중 정지하는 것을 의미한다.

- 크래시 리포트(Crash Report)는 사용자 단말에서 일어난 크래시에 대한 모든 정보를 크래시 리포트 앱 또는 모듈이 캐치하여 정리한 리포트로서, 크래시 로그 파일이 그 일례이다. 크래시 로그 파일에는 헤더, 스택 트레이스, 크래시 발생 위치, CPU 사용량, 또는 크래시 캡쳐 사진 등 크래시에 관한 다양한 정보가 포함될 수 있다.

- 예외(Exception)는 프로그램 실행 중에 발생할 수 있는 예기치 않은 오류를 의미한다.

- 크래시 예외 타입은 크래시 로그 파일 중 헤더 또는 스택 트레이스 필드에 기재되어 있는 것으로, 예외 타입은 단말기 애플리케이션에 연관된 크래시 리포팅 모듈이 캐치한 후 로그 파일에 기재하여 서버로 보내온다. 예외 타입의 유형은 크게 POSIX 신호 유형과 Exception 유형이 있다. POSIX 신호란 유닉스 계열, POSIX 호환 운영체제에서 쓰이는 프로세스 신호로 운영체제에서 프로세스의 예외적인 상황을 보고한다. 신호 종류에 따라 해당 신호를 받은 프로세스는 이를 무시하거나, 이후 진행이 불가능하거나, 프로그램을 중지 시키는 등의 처리를 한다. POSIX 신호의 예로서 SIGABRT(프로세스 중단 신호), SIGBUS(정의되지 않은 메모리 오브젝트의 일부분에 접근), SIGFPE(오류가 있는 산술 조작), SIGILL(유효하지 않은 명령),　SIGSEGV(잘못된 메모리 참조) 등이 있다. Exception의 예에는 NullReferenceException(객체주소가 없음), IndexOutOfBoundException(객체배열에서 지정된 인덱스가 참조할 수 없음), IllegalStateException(객체상태가 메쏘드 호출에 적합하지 않음) 등이 있다.

- 크래시 위치(location)는 실제 크래시가 발생한 플랫폼, 언어계층 또는 애플리케이션 개발엔진의 종류를 의미한다. iOS/Android(운영체제), Java/C#(Virtual Machine 언어), Native(하드웨어 친화적인 저레벨 언어, 운영체제가 구현된 언어), 게임엔진종류(Unity, Unreal, cocos2d 등)로 구분될 수 있다. 예를 들어, Android Unity Native Crash, iOS Native Crash, Java Exception, Android C# Script Exception, Android Native Crash 등이 있다.

Java Exception과 Android C# Script Exception은 엄밀히 구분하면 애플리케이션의 예외이나 본 발명에서 크래시로 분류하는데, 스택 트레이스에 클래스와 메쏘드 명이 상세히 나온다. Android Unity Native Crash는 예외적인 경우로서 NDK에서 크래시를 캐치하기 전에 Unity 단에서 직접 크래시를 캐치하여 스택 트레이스를 만들어 보내주는데, 별도의 매핑 과정은 필요가 없다. Android 및 iOS Native Crash인 경우 크래시가 발생하였을 때 메모리 주소 덤프파일로 떨어지기 때문에 쉽게 식별할 수 있는 클래스로 매핑하기 전에는 메모리 주소로 된 스택 트레이스를 이용하여 그룹핑을 진행할 수 있다. 쉽게 식별할 수 있는 클래스, 메쏘드 이름으로 메모리 주소들이 매핑되면 의미있는 메쏘드 라인을 구별하여 그룹핑을 진행할 수 있다.

- 메소드(Method)는 어떤 로직을 수행하는 함수이다.

- 스택 트레이스(Stacktrace)는 오류가 발생했을 때의 시점 및 그 이전의 메쏘드, 클래스, 라이브러리 호출 목록을 의미하는데, 복수개의 라인으로 구성되어 있다.

- 크래시 그룹 타입은 크래시 스택 트레이스에 나타난 트러블 슈팅에 용이한 라인들 중 최상위 코드 구현 레벨을 구분하는 크래시 타입으로서, 애플리케이션 크래시 그룹, 애플리케이션 개발 엔진 크래시 그룹, 시스템 크래시 그룹이 있다. 크래시 그룹 타입의 순위는 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 순으로 높다.

- 그룹핑(Grouping)은 같은 종류의 것으로 분류하거나 묶는 것을 의미한다.

- 시스템 라이브러리, 클래스 또는 메쏘드는 Device, OS, OS-SDK 관련 라이브러리, 클래스 또는 메쏘드를 포함하고, 시스템 라이브러리는 시스템 프레임워크(System Framework)라고도 한다.

- 루트 코즈(Root Cause)는 어느 사건의 근본적인 원인을 의미한다.

- 심볼화(Symbolication)는 16진수로 표시된 주소들을 심볼(Symbol) 파일들을 이용해서 함수명으로 매핑하여 스택 트레이스를 사람이 읽을 수 있는 형식으로 변환하는 작업이다.

- NDK(Native Development Kit)는 안드로이드(Android)의 SDK(Android Software Development Kit)외에 직접 안드로이드 기본 인터페이스를 프로그래밍할 수 있도록 C/C++ 네이티브 개발을 지원하는 개발 도구이다.

- 네이티브 크래시(Native Crash)는 프로그램 실행 중 발생한 크래시 중 자바(Java)나 C# Script과 같은 애플리케이션 단이 아닌 단말 OS의 네이티브(Native) 단에서 캐치(catch)된 크래시이다.

- 게임 엔진(Game Engine)은 게임 개발을 위한 다양한 기능을 제공하는 소프트웨어 기반 툴(프레임워크)로서, 게임 개발엔진으로도 불리운다.

- 유니티(Unity)는 다양한 플랫폼을 제공하는 Unity사의 게임 엔진이다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 실시예를 상세하게 설명한다. 본 발명의 구성 및 그에 따른 작용 효과는 이하의 상세한 설명을 통해 명확하게 이해될 것이다.

본 발명의 상세한 설명에 앞서, 동일한 구성요소에 대해서는 다른 도면상에 표시되더라도 가능한 동일한 부호로 표시하며, 공지된 구성에 대해서는 본 발명의 요지를 흐릴 수 있다고 판단되는 경우 구체적인 설명은 생략하기로 함에 유의한다.

도 1은 본 발명에 따른 크래시 리포트 그룹핑을 수행하는 시스템의 개략적인 구성도로서, 사용자 단말기(10), 크래시 리포트 그룹핑 서버(20), 애플리케이션 서버(30) 및 네트워크(40)를 포함할 수 있다. 사용자 단말기(10)는 애플리케이션 사용자가 가지고 있는 단말기를 말한다. 네트워크는 유선 또는 무선 네트워크가 될 수 있다. 이하에서 예로써 애플리케이션(101)은 게임 애플리케이션이고, 애플리케이션 서버(30)는 게임 서버이며, 사용자 단말기(10)는 모바일 단말기일 수 있다. 모바일 단말기일 경우, 스마트폰이나 태블릿 PC 등의 모바일 디바이스이나 게임 애플리케이션을 설치하여 실행할 수 있는 기기라면 어떠한 종류의 디바이스라도 가능하다. 사용자 단말기(10)는 게임 애플리케이션을 설치하고 게임 서버(30)에 접속하여 게임을 진행한다. 사용자 단말기(10)에 설치된 게임 애플리케이션(101)에는 크래시 리포팅 모듈(102)이 내장되어 있을 수 있다. 크래시 리포팅 모듈(102)은 애플리케이션에서 발생되는 크래시를 캐치하여 크래시 로그파일을 생성한 후 크래시 리포트 그룹핑 서버(20)로 송신될 수 있도록 하는 기능을 수행한다.

게임 서버(30)는 게임개발업체가 구축하여 운영 및 관리하거나 복수의 게임을 서비스하는 업체나 퍼블리싱(publishing) 업체가 게임개발업체로부터 넘겨받아 직접 운영 및 관리할 수 있다. 크래시 리포트 그룹핑 서버(20)는 사용자 단말기(10)에서 게임 진행시 발생되는 크래시 리포트(예, 크래시 로그 파일)을 수신하여 크래시 유형을 분석하여 그룹핑을 수행한다. 크래시 리포트 그룹핑 서버(20)는 게임 서버(30)와 구별되는 구성으로 되어 게임개발업체 또는 퍼블리싱 업체에 위치할 수 있다. 또는, 도 1과 달리 크래시 리포트 그룹핑 서버(20)는 애플리케이션 서버(30) 내의 일부로 구성될 수도 있다.

그룹핑된 크래시 리포트는 트러블 슈팅(trouble shooting)을 위하여 게임 개발자에게 전송된 후, 게임 애플리케이션이 업데이트되고 사용자 단말기에 다운로드 될 것이다(미도시).

도 2는 본 발명에 따른 크래시 리포트 그룹핑 서버(40)의 일례의 내부 구성도이다. 크래시 리포트 수신부(201)가 사용자 단말기(10)로부터 크래시 로그파일을 수신하여 크래시 리포트 그룹핑 서버(40)의 각 구성부분에 전달한다. 크래시 위치 확인부(202)는 크래시 로그 파일을 수신하고 로그 파일내 필드 중 헤더 또는 스택 트레이스가 존재하는 필드와 구별되는 별도의 필드에 기록된 크래시가 발생한 위치 정보를 크래시 위치 DB(212)를 참조하여 확인한 후 크래시 리포트 매칭부(206)로 보낸다. 크래시 발생위치는 플랫폼, 언어계층 또는 게임엔진 종류 또는 이들의 조합으로 표기될 수 있다. 구체적인 예에서, 플랫폼은 iOS 또는 Android 운영체제이고, 상기 언어 계층은 Java 또는 C# 가상머신(VM) 언어계층, 또는 C 또는 C++ Native 언어계층이고, 상기 게임 애플리케이션 개발엔진 종류는 Unity, Unreal 또는 cocos2d이다. 상기 크래시 위치는 Android 크래시인 경우는 Java Exception, Android Unity Native Crash, Android Native Crash 및 C# Script Exception 중 하나이고, iOS 크래시인 경우는 iOS Native Crash 및 C# Script Exception 중 하나일 수 있다.

크래시 예외 타입 확인부(203)는 크래시 예외 타입 DB(213)을 참조하고, 크래시 로그 파일내 헤더(Header) 또는 스택 트레이스내에 기재된 크래시 예외 타입을 확인하여, 해당 정보를 크래시 리포트 매칭부(206)로 보낸다.

스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)는 크래시 리포트 수신부(201)로부터 혹은 심볼화부(210)로부터 크래시 로그파일을 수신한 후, 크래시 리포트를 서로 구분하는데 유용한 라인만 유지하고 나머지 라인은 제거하여 정제된 스택 트레이스를 추출하여 크래시 리포트 매칭부(206) 및/또는 크래시 그룹 타입 분류부(205)로 보낸다. 상기 라인 제거는 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 먼저 제거한 후, 애플리케이션 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 제거하되, 스택 트레이스의 라인별로 시스템 또는 개발엔진 라이브러리 이름, 클래스 이름 또는 메쏘드 이름을 확인하고 스택 트레이스 라인 DB(214)를 참조하면서 라인 제거를 진행한다. 스택 트레이스 라인 DB(214)에는 시스템 라인들, 애플리케이션 개발엔진 라인들 및 애플리케이션 라인들에 각각 관련된 라이브러리 이름, 클래스 이름 및 메쏘드 이름의 데이터가 저장되어 있다.

크래시 리포트 수신부(201)로부터 수신한 스택 트레이스에서 시스템에 관련된 라인들과 애플리케이션 개발엔진에 관련된 라인들을 제거하고 애플리케이션에 관련된 라인들을 남기되, 상기 제거 이전의 스택 트레이스에 상기 시스템에 관련된 라인들만 있었던 경우는 상기 시스템에 관련된 라인들의 일부 또는 전부를 남기고, 상기 제거 이전의 스택 트레이스에 상기 애플리케이션 개발엔진에 관련된 라인들만 있거나 또는 상기 시스템 관련 라인들과 상기 애플리케이션 개발엔진에 관련된 라인들만 있는 경우는 상기 애플리케이션 개발엔진에 관련된 라인들의 일부 또는 전부를 남긴다.

구체적으로, 만일 상기 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부를 제거한 후 스택 트레이스에 어떠한 라이브러리 이름을 포함하는 라인도 존재하지 않으면, 상기 제거된 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부 또는 전부를 회복시켜서, 정제된 스택 트레이스로 추출한다. 일부 라인들만 회복시킬 경우, 회복되는 일부 스택 트레이스 라인들은 크래시 리포트들을 서로 구분하는데 유용한 라인들이고, 회복되지 못하거나 제거되는 스택 트레이스 라인들은 크래시 리포트들 사이에 공통되는 라인들 또는 스택 트레이스 라인의 일부 정보가 누락된 라인들, 또는 런타임마다 달라지는 메쏘드를 포함하는 라인 등 크래시 리포트 구분에 유용하지 않은 라인들이다. 만일, 시스템 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있으면, 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들을 전부 제거한 후 스택 트레이스에 라이브러리 이름을 포함하는 라인이 남아 있는지를 확인한다. 만일, 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하지 않으면, 상기 제거된 개발엔진 라이브러리, 클래스 또는 메쏘드 이름을 포함하는 라인들 중 일부 또는 전부를 회복시켜서, 정제된 스택 트레이스로서 추출한다. 만일, 스택 트레이스에 라이브러리 이름을 포함하는 개발엔진 관련 라인들을 전부 제거한 후에도 스택 트레이스에 라이브러리 이름을 포함하는 라인이 존재하면, 남아있는 스택 트레이스의 라인을 정제된 스택 트레이스로 추출한다.

전술한 제거 방식에 따르면, 스택 트레이스에 시스템에 관련된 라인들, 애플리케이션 개발엔진에 관련된 라인들, 애플리케이션에 관련된 라인들이 모두 있는 경우는 애플리케이션에 관련된 라인들만 남아 정제된 스택 트레이스로 추출된다. 그런데, 애플리케이션 라이브러리 이름을 포함하는 라인들의 일부를 제거할 수도 있는데, 상기 제거되는 애플리케이션 라이브러리 이름을 포함하는 라인은 크래시 리포트들을 서로 구분하는데 유용하지 않은 라인들로서, 애플리케이션 개발엔진 클래스 또는 메쏘드 이름을 포함하는 라인이거나, 서로 중복된 라인, 또는 크래시 리포트들 사이에서 공통되는 라인들, 또는 일부 정보가 누락된 라인들, 또는 런타임마다 달라지는 메쏘드를 포함하는 라인들이 해당될 수 있다.

스택 트레이스는 헤더와 구분될 수 있으나, 만일 스택 트레이스가 헤더를 포함하는 경우라면 상기 제거기능은 스택 트레이스에서 헤더도 제거하는 것을 포함할 수 있다.

상기 스택 트레이스 라인 제거없이 아래와 같이 정제된 스택 트레이스 추출도 가능할 수 있다. 즉, 스택 트레이스 라인들에서 애플리케이션에 관련된 라인들이 있으면 그 일부 또는 전부를 먼저 추출하여 정제된 스택 트레이스로 한다. 만일, 애플리케이션에 관련된 라인이 없는 경우, 애플리케이션 개발엔진에 관련된 라인들이 있는지를 확인하고 존재하면 그 일부 또는 전부를 정제된 스택 트레이스로서 추출한다. 애플리케이션 및 애플리케이션 개발엔진에 관련된 라인이 없는 경우, 남아있는 라인들, 즉 시스템에 관련된 라인들의 일부 또는 전부를 정제된 스택 트레이스로서 추출할 수 있다.

크래시 그룹타입 분류부(205)는 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)로부터 정제된 스택 트레이스 라인들을 수신한 후, 이 라인들이 관련된 크래시 그룹타입을 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 중 어느 하나의 타입으로 분류하고, 그 정보를 크래시 리포트 매칭부(206)로 보낸다. 이와 선택적으로, 크래시 그룹타입 분류부(205)는 크래시 리포트 수신부(201)로부터 크래시 로그 파일을 받아서, 트러블 슈팅에 용이한 라인들 중에서 최상위 코드 구현 레벨을 구분해내도록 구성할 수도 있다. 구체적으로, 상기 크래시 그룹 타입의 순위는 애플리케이션 크래시 그룹, 개발엔진 크래시 그룹 및 시스템 크래시 그룹 순으로 높은데, 상기 크래시 그룹 타입은 상기 제거 단계전 스택 트레이스 라인들을 각 라인별로 검토하면서 관련된 각 크래시 그룹을 확인하되 관련된 크래시 그룹들 중에서 최상위 크래시 그룹을 해당 로그 파일의 크래시 그룹타입으로 분류할 수 있다.

실시예에 따라서 크래시 그룹타입 분류부(205)에 의해 수행되는 크래시 그룹타입 분류는 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)에서 함께 수행될 수도 있다.

스택 트레이스 해싱부(208)는 예를 들어, 크래시 위치(crash location)가 AOS 또는 iOS의 Native Crash 경우, 스택 트레이스 라인들이 메모리 주소값을 포함할 수 있는데, 해시 알고리즘을 사용하고 스택 트레이스 해싱 DB(209)를 참조하여 메모리 주소값을 포함하는 스택 트레이스 라인들에 대응하는 고정된 길이의 키값인 해시 키를 생성할 수 있다.

심볼화부(210)는 심볼화 DB(211)을 참조하여 스택 트레이스 라인들의 메모리 주소값에 대응하는 클래스 이름 및/또는 메쏘드 이름으로 매핑한다. 만일 심볼화가 실패한 경우, 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)는 기능을 수행할 수 없고, 스택 트레이스 해싱부(208)에서 생성된 해시 값이 크래시 리포트 매칭부(206)에서 활용될 수 있다.

반면, 스택 트레이스 라인에 메모리 주소값이 아닌, 라이브러리 이름, 클래스 이름 및/또는 메쏘드 이름으로 구성되어 있는 경우는 스택 트레이스 해싱부(208)와 심볼화부(210)는 해싱 및 심볼을 각각 수행할 수 없고, 필요가 없다.

크래시 리포트 매칭부(206)는 크래시 위치 확인부(202)로부터 수신한 크래시 위치, 크래시 예외 확인부(203)로부터 수신한 예외 타입, 정제된 스택 트레이스 추출부(204)로부터 수신한 추출된 정제된 스택 트레이스, 이 정제된 스택 트레이스의 최상위 라인인 루트 코즈 라인을 대표 크래시 리포트 DB(207)에 저장된 원인별 대표 크래시 리포트들의 크래시 위치, 예외 타입, 정제된 스택 트레이스, 루트 코즈 라인과 비교하여 매칭되는 대표 크래시 리포트를 확인해낸다. 해당 게임 애플리케이션을 식별하는 앱코드도 서로 비교하여 매칭에 활용할 수 있다(미도시).

또한, 크래시 그룹타입 분류부(205)로부터 수신한 크래시 그룹 타입을 대표 크래시 리포트의 크래시 그룹 타입과 비교하여 매칭하는데 활용할 수 있다. 애플리케이션 크래시 그룹타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스가 상호 동일한 경우 매칭되는 것으로 판단할 수 있다. 개발엔진 크래스 그룹타입이거나 시스템 크래시 그룹타입인 경우는 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스가 상호 유사한 경우 매칭되는 것으로 판단할 수 있다. 상기 추출된 정제된 스택 트레이스와 상기 대표 크래시 리포트의 정제된 스택 트레이스의 상호 유사 여부는 루트 코즈 라인은 서로 동일하고, 상호 일치하는 스택 트레이스의 라인 개수의 비율이 일정 퍼센트 이상, 예를 들어, 70% 이상이면 유사한 것으로 보고 매칭된다고 판단할 수 있다.

만일 매칭이 되는 대표 크래시 리포트가 없는 경우, 상기 크래시 위치, 상기 예외 타입, 상기 크래시 그룹 타입, 상기 루트 코즈 라인 및 상기 추출된 정제된 스택 트레이스를 포함하는 새로운 대표 크래시 리포트로 분류하고, 대표 크래시 리포트 DB(207)에 저장한다.

크래시 위치가 Andorid Native Crash 또는 iOS Native Crash이나 심볼화부(210)에서 심볼화가 실패한 경우, 크래시 리포트 매칭부(206)는 크래시 위치, 예외 타입 및 스택 트레이스의 해시 값을 대표 크래시 리포트 DB를 참조하여 대표 크래시 리포트들의 크래시 위치, 예외 타입 및 스택 트레이스의 해시 값과 비교하여 매칭여부를 판단할 수 있다.

크래시 리포트 매칭부(206)는 크래시 위치, 예외 타입, 앱코드를 기준으로 매칭여부를 판단하여 1차 크래시 리포트 그룹핑을 한 후, 크래시 그룹 타입, 루트 코즈 라인, 정제된 스택 트레이스를 기준으로 상기 매칭여부를 추가 판단하는 2차 크래시 리포트 그룹핑을 수행할 수 있다. 대표 크래시 리포트 DB(207)는 앱코드별로 구성되고, 각 앱코드별 DB내에는 다수의 대표 크래시 리포트들 중 예외 타입 및 크래시 위치가 동일한 대표 크래시 리포트들을 하나의 1차 그룹으로 구분하는 방식으로 된 복수개의 1차 그룹이 포함될 수 있다. 각각의 1차 그룹내에는 크래시 그룹타입, 루트 코즈 라인, 정제된 스택 트레이스 또는 스택 트레이스 해시값이 동일한 대표 크래시 리포트들(또는 이들 동일한 항목들은 스택 트레이스와 관련된 것이므로, 대표 스택 트레이스라고도 명명할 수 있음)을 하나의 2차 그룹으로 분류하는 방식으로 된 복수개의 2차 그룹이 포함될 수 있다. 이에 따라, 전술한 1차 및 2차 크래시 리포트 그룹핑을 통한 매칭을 효과적으로 수행할 수 있다.

다음 표 1은 앞서 설명한 대표 크래시 리포트의 포맷을 요약한 것이다. 아래 표 1에서 좌측열에 있는 정보는 1차 크래시 리포트 그룹핑에 활용되고, 우측열에 기재된 정보는 2차 크래시 리포트 그룹핑에 활용될 수 있다. 우측열에 표시된 정보 중에서 '라인수(스택 트레이스 라인 개수)'는 그룹핑 속도 개선을 위한 속성으로서 그룹핑을 위한 비교에서 필수적인 특징은 아니다.

앱 코드 - 게임 애플리케이션별 코드	그룹 타입(아래 타입 중 하나) - 게임 크래시 - 엔진 크래시 - 시스템 크래시
크래시 위치(아래 크래시 위치의 예시 중 하나) - Android Java Exception - Android Unity Native Crash - Android Native Crash - Android C# Script Exception - iOS Native Crash - iOS C# Script Exception
	라인 수 - 스택 트레이스 라인 개수
	루트 코즈 라인 - 크래시 원인 라인
예외 타입(아래 예외 타입의 유형 중 하나) - POSIX 시그널 - Exception 이름	스택트레이스(아래 데이터 중 하나) - 정제된 스택 트레이스 - 스택 트레이스 해시 값

도 3a 및 3b는 본 발명의 일실시예에 따른 크래시 리포트 그룹핑 서버의 처리 과정을 나타낸 순서도이다. 크래시 리포트 수신부(201)가 크래시 리포트를 수신한 후(S300), 크래시 위치, 예외 타입, 앱 코드를 식별하고(S302 및 도 2의 202, 203 참조), 이 정보를 토대로 크래시 리포트 매칭부(206)에서 1차 크래시 리포트 그룹핑을 수행한다(S304). 다음으로, 크래시 예외 타입이 Android Native Crash이거나 iOS Native Crash인지 여부를 확인하고(S306), 만일 이와 다른 예외 타입으로 확인이 되면, 스택 트레이스에서 시스템 관련 라인들을 라인별(line by line)로 확인하며 제거한다(S308). S308 단계이후, 스택 트레이스 라인이 남아 있는지 확인하고(S310), 스택 트레이스 라인이 남아 있으면 스택 트레이스에서 애플리케이션 개발엔진 관련 라인을 제거하고(S312), S310 단계에서 남은 스택 트레이스 라인이 없는 것으로 확인하면 제거한 시스템 관련 스택 트레이스 라인의 일부를 회복한다(S322). 단계 S312를 통한 스택 트레이스 라인제거 후에도 스택 트레이스 라인이 남아 있는지 확인(S314)하고, 남아 있지 않으면 제거된 애플리케이션 개발엔진 관련 라인의 일부를 회복시킨다(S324). 단계 S322와 S324에서 회복되는 일부 라인과 회복되지 않고 제거되는 일부 라인들에 대한 판단 기준은 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)와 관련하여 전술한 바와 같다. 구현례에 따라서 단계 S322와 S324에서 선택적으로 회복하지 않고 제거된 전체 라인을 회복시킬 수도 있다. 단계 314를 거쳐 남은 스택 트레이스 라인, 즉, 애플리케이션 관련 스택 트레이스 라인들, 또는 단계 322와 단계 324를 통해 회복된 시스템 관련 라인들 또는 개발엔진 관련 라인들은 정제된 스택 트레이스로서 추출되고, 정제된 스택 트레이스에서 최상위 라인, 즉 맨 앞쪽 라인은 루트 코즈 라인으로 추출된다(S316). 추출된 정제된 스택 트레이스는 시스템, 애플리케이션 개발엔진, 애플리케이션 중 어느 하나와 관련되어 있으므로, 그 관련성을 바탕으로 크래시 그룹 타입을 분류한다(S318). 추출된 정제된 스택 트레이스, 루트 코즈 라인, 크래시 그룹 타입을 바탕으로, 앞서 1차 분류된 크래시 리포트 그룹내의 복수의 서브 그룹 중에서 매칭되는 크래시 리포트 서브 그룹(2차 그룹)을 확인한다(S320).

전술한 단계 S306에서 예외 타입이 Android Native Crash 또는 iOS Native Crash인 경우는 스택 트레이스를 해싱(S326)하고 심볼화(S328, S330)를 거쳐서 시스템관련 라인을 제거하는 단계(S308)로 밟게 된다. 단계 S326과 S328은 순서가 바뀌어도 가능하다. S328에서 심볼화가 가능하지 않는 경우, 단계 S326를 통해 생성된 스택 트레이스 해시 값을 이용하여 2차 크래시 리포트 그룹핑(S320)을 진행할 수 있다.

도 4는 도 3b에 따른 크래시 리포트 그룹핑 서버의 동작 중에서 2차 크래시 리포트 그룹핑(S320) 과정을 상세히 설명하는 순서도이다. 먼저, 스택 트레이스 라인이 해시값으로 정의되어 있는 지를 확인하고(S400), 만일 그렇지 않으면, 추출된 정제된 스택 트레이스가 애플리케이션 크래시 그룹타입 여부를 확인한다(S402). 애플리케이션 크래시 그룹타입인 경우, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207)에 저장된 기분류된 동일한 1차 크래시 리포트 그룹내에 있는 다수의 대표 크래시 리포트들의 정제된 스택 트레이스('대표 스택 트레이스'로 칭함)와 각각 비교하여 서로 동일한 스택 트레이스가 있는 지를 판단한다(S404). 동일한 대표 스택 트레이스가 있으면 해당 대표 스택 트레이스로 매칭하고(S406), 동일한 대표 스택 트레이스가 없으면, 추출된 정제된 스택 트레이스를 신규 대표 스택 트레이스로 대표 크래시 리포트 DB(207) 내의 기분류된 동일한 1차 크래시 리포트 그룹내에 추가한다(S412).

단계 S402에서 애플리케이션 크래시 그룹타입이 아닌 경우, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207)에 저장된 기분류된 동일한 1차 그룹내의 다수의 대표 스택 트레이스와 각각 비교하여, 루트 코즈 라인이 동일하고(S408) 상호 일치하는 스택 트레이스 라인의 개수가 예를 들어, 70% 이상인지를 확인하고(S410), 두 조건을 만족하는 대표 스택 트레이스에 매칭한다(S406). 만일 위 두 조건 중 적어도 어느 하나를 만족하지 못하면, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207) 내 기분류된 동일한 1차 그룹내에 추가한다(S412).

단계 S400에서 수신된 스택 트레이스 라인이 해시값으로 정의되어 있으면, 수신된 스택 트레이스의 해시값을 기분류된 동일한 1차 그룹내에 있는 다수의 대표 스택 트레이스의 해시값과 각각 비교하여 동일한 대표 스택 트레이스를 확인한다(S414). 해시값이 동일한 기존의 대표 스택 트레이스가 있으면 이 대표 크래시 리포트로 매칭시키고(S406), 해시값이 동일한 기존 대표 스택 트레이스가 없으면 신규 대표 스택 트레이스로 대표 크래시 리포트 DB(207) 내 기분류된 1차 그룹에 추가한다(S412).

다음은 크래시 로그파일의 헤더와 스택 트레이스 샘플을 통해 본 발명을 설명한다. 설명 편의를 위하여 로그파일 라인에 일련 번호를 부여하였다.

[샘플 1]

1 java.lang.Error: signal 11 (SIGSEGV), code 0 (?), fault addr 0000361b

2 Build fingerprint: 'samsung/arubaslimxx/arubaslim:4.1.2/JZO54K/I8262XXAND1:user/release-keys'

Revision: '0'

3 pid: 13851, tid: 16562, name: UnityMain >>> com.netmarble.mherosgb <<<

4 r0 00000000 r1 0000000b r2 00000001 r3 400fe7ac

5 r4 53a26c04 r5 5ef09ec0 r6 68781de8 r7 00000025

6 r8 00000000 r9 59c374b0 sl 6465f9b0 fp 5484dcd4

7 ip fffd406c sp 5484dcb8 lr 53926370 pc 400c7cf8 cpsr 354f5a4a

8 at libc.kill(kill:12)

9 at libmono.002ad36c(Native Method)

10 at libmono.002ad468(Native Method)

11 at libmono.002ad4c4(Native Method)

12 at libmono.0011b2b4(Native Method)

13 at libmono.0011b550(Native Method)

14 at libmono.0011bbc4(Native Method)

15 at libmono.0012a750(Native Method)

16 at libmono.000ede20(Native Method)

17 at Summoners.GetSummoner(Native Method)

18 at Summoners.GetSummoner(<0x00128>:296)

19 at Summoners.SummonMyFriend(<0x00027>:39)

20 at ClickSummon.OnClick(<0x000b7>:183)

21 at Object.runtime_invoke_void__this__(Native Method)

22 at GameObject.SendMessage(Native Method)

23 at UICamera.Notify(<0x00068>:104)

24 at UICamera.ProcessTouch(<0x00bbf>:3007)

25 at UICamera.ProcessTouches(<0x003d3>:979)

26 at UICamera.Update(<0x000ff>:255)

27 at Object.runtime_invoke_void__this__(Native Method)

28 at libmono.00023bbb(Native Method)

29 at libmono.mono_runtime_invoke(mono_runtime_invoke:136)

30 at libunity.00216e6c(Native Method)

31 at libunity.002d63ec(Native Method)

32 at libunity.002d63a8(Native Method)

33 at libunity.0020243c(Native Method)

34 at libunity.00202450(Native Method)

35 at libunity.001e8e3c(Native Method)

36 at libunity.001e9384(Native Method)

37 at libunity.002a0e14(Native Method)

38 at libunity.003d3c1c(Native Method)

앱코드는 라인 3번에 표시된 'mherosgb'인데 도시가 생략된 앱코드 확인부 및 앱코드 DB를 참조하여 확인할 수 있다. 크래시 위치가 표시된 크래시 로그파일의 필드는 위 샘플에 표시되지 않았는데, "Crash location: Android Unity Native Crash"라는 로데이터(raw data)가 확인된 것으로 가정한다. 크래시 위치는 Crash location이라는 별도의 필드 제목을 포함하여 수신하므로 확인이 용이하고 DB(212)를 참조하여 컨펌할 수 있는데, 스택트레이스/헤더와 별개의 필드에 존재할 수 있고, 메모리/CPU 사용량 등과 같은 형식으로 전달될 수 있다. 그리고 설명의 편의상 하기의 각 기능을 수행하는 도 2의 구성요소의 특정은 본 샘플 설명에서 설명에 필요한 최소한으로만 언급하고, 설명의 순서는 도 3 내지 도 4의 순서도에 최대한 부합하도록 설명한다. 라인 1 내지 7은 헤더에 해당하는데, 크래시 예외 타입 DB(213)에 기록된 크래시 예외 타입 중 POSIX 신호 유형의 하나인 SIGSEGV을 라인 1에서 크래시 예외 타입 확인부(203)가 확인할 수 있다. SIGSEGV는 잘못된 메모리 참조를 의미하는 예외 타입이다. 이들 정보로 1차 크래시 리포트 그룹핑이 가능하다.

다음으로, 크래시 위치가 Android Unity Native Crash이므로 스택 트레이스 라인 제거단계로 진행한다. 라인 8 내지 라인 38로 이루어진 스택 트레이스에서 스택 트레이스 라인제거부 및 정제된 스택트레이스 추출부(204)가 라인 8부터 순차적으로 내려가면서 스택 트레이스 라인 DB(214)를 참조하여 시스템에 관련된 라인을 제거한다. 라인 8은 libc가 시스템 라이브러리 이름, kill이 시스템 관련 메쏘드, 12가 위치를 의미하므로 시스템 관련 스택 트레이스 라인에 해당되어 제거된다. 라인 9 내지 라인 38까지 시스템 관련 라인은 발견되지 않는다. 시스템 관련 라인 제거 후에도 다수의 스택 트레이스 라인(라인 9 내지 38)이 남아 있으므로, 다음으로 애플리케이션 개발엔진 관련 라인을 제거한다. 라인 9는 libmono가 게임 개발엔진 라이브러리 이름, 002ad36c가 메쏘드의 주소, Native Method가 Native 언어로 구현된 메쏘드를 의미를 의미하므로 게임 개발엔진 라인에 해당되어 제거된다. 같거나 유사한 이유로 스택 트레이스 라인 DB(209)를 참조하면서 라인 10 내지 16, 라인 21 내지 라인 38을 순차적으로 제거한다. 게임 개발엔진 라인 제거 후에도 스택 트레이스 라인 17 내지 20이 남아 있다. 이들 라인은 애플리케이션 관련 라인들이다. 이들 라인들을 정제된 스택 트레이스로 추출하고, 최상위 라인 17을 루트 코즈 라인으로 할 수 있다. 그런데, 더 효과적인 그룹핑을 위해서 남아 있는 애플리케이션 관련 라인들 중에서 위치 정보가 없는 라인들은 추가로 삭제하도록 스택 트레이스 라인 제거부 및 정제된 스택 트레이스 추출부(204)를 설정할 수 있다. 그러한 경우, 17 내지 20 중에서 위치 정보가 없는 라인 17을 추가로 삭제하고, 라인 18 내지 20을 정제된 스택 트레이스로 추출하고, 라인 18을 루트 코즈 라인으로 추출할 수 있다. 그리고, 추출된 정제된 스택 트레이스가 게임(애플리케이션) 관련 트레이스 라인들이므로, 크래시 그룹 타입을 게임(애플리케이션) 그룹 타입으로 분류한다.

해시 값으로 표시되지 않는 정제된 스택 트레이스가 추출되었고, 게임 크래시 그룹 타입이므로, 추출된 정제된 스택 트레이스를 대표 크래시 리포트 DB(207) 내의 1차 그룹핑된 그룹내의 여러 서브 그룹의 대표 스택 트레이스와 각각 비교하면서, 동일한 대표 스택 트레이스를 검색하여 매칭한다. 매칭되지 않으면, 대표 크래시 리포트 DB(207)내의 1차 그룹내에 신규 서브그룹을 만들고 신규 대표 스택 트레이스로 저장한다.

이렇게 추출된 정제된 크래시 리포트는 특히, 루트 코즈 라인과 스택 트레이스를 보고 트러블 슈팅을 위한 단서를 유추하는데 사용될 것이다. 위 샘플 1의 경우, 게임 개발자가 구현한 게임 로직 중에서 Summoner라는 객체를 얻는 GetSummoner 메쏘드가 실행되다가 잘못된 메모리를 참조하는 로직이 수행되어 크래시가 생겼다고 유추할 수 있다.

[샘플 2]

아래 샘플은 심볼화 과정을 거친 후의 iOS Native Crash 로그의 스택 트레이스 중 일부를 발췌한 것이다.

Full2016 EventDelegate_Execute_m213950963 (in full2016) (Bulk_Assembly-CSharp_4.cpp:10246)

Full2016 EventDelegate_Execute_m895247138 (in full2016) (Bulk_Assembly-CSharp_4.cpp:10904)

Full2016 UIButton_OnClick_m1558826940 (in full2016) (Bulk_Assembly-CSharp_22.cpp:11351)

Full2016 RuntimeInvoker_Void_t2863195528(MethodInfo const*, void*, void**) (in full2016) (Il2CppInvokerTable.cpp:1262)

iOS의 경우, 게임엔진 라이브러리 이름이 별도로 없고 게임 라이브러리 이름만 존재하므로, 게임엔진 관련 스택 트레이스 라인은 게임엔진에 관한 클래스 명칭 또는 메쏘드 명칭을 통해 구분할 수 있다. 위 샘플 2의 각 스택 트레이스 라인의 라이브러리 이름은 Full2016인데 이 라이브러리 이름은 게임 라이브러리와 게임엔진 라이브러리가 공통으로 사용하는데, 이어서 기재된 클래쓰(예, EventDelegate)와 메쏘드(예, Execute_m213950963)가 게임엔진에 관련된 것이므로, 샘플 2의 모든 스택 트레이스 라인들은 게임엔진 관련 라인으로 이해될 수 있다. 이러한 판단은 스택 트레이스 라인 DB(214)에 저장된 iOS 게임 라이브러리 이름 등의 정보를 바탕으로 가능하게 된다.

[샘플 3]

크래시 위치가 크래시 로그 파일의 다른 필드에서 iOS Native Crash 로그로 확인되었다고 전제하고 아래는 크래시 로그 파일 중 스택 트레이스와 헤더를 발췌한 것이다.

*** Terminating app due to uncaught exception '(null)', reason: '(null)'

Incident Identifier: B1DCB953-DAB0-47EA-AA44-D8F6316C859A

Hardware Model: iPhone5,2

Process: full2016 [1454]

Path: /var/containers/Bundle/Application/6F542B8E-7B13-4C1A-90CC-4EBAAF4BDD85/full2016.app/full2016

Identifier: com.netmarble.full2016

Version: 1231

Code Type: ARM

Parent Process: ??? [1]

Date/Time: 2017-03-12T15:12:06Z

OS Version: iPhone OS 10.2.1 (14D27)

Report Version: 104

Exception Type: SIGABRT

Exception Codes: #0 at 0x1ca24ad4

Crashed Thread: 0

Thread 0 Crashed:

0 libsystem_kernel.dylib 0x1ca24ad4 0x1ca0e000 + 92884

1 libsystem_c.dylib 0x1c9b8339 0x1c96d000 + 308025

2 libc++abi.dylib 0x1c4bc569 0x1c4bb000 + 5481

3 libc++abi.dylib 0x1c4d650f 0x1c4bb000 + 111887

4 libobjc.A.dylib 0x1c4df305 0x1c4d8000 + 29445

5 libc++abi.dylib 0x1c4d393f 0x1c4bb000 + 100671

6 libc++abi.dylib 0x1c4d3443 0x1c4bb000 + 99395

7 libobjc.A.dylib 0x1c4df1bb 0x1c4d8000 + 29115

8 CoreFoundation 0x1d1855a1 0x1d17b000 + 42401

9 CoreFoundation 0x1d185341 0x1d17b000 + 41793

10 GraphicsServices 0x1e95cbfd 0x1e953000 + 39933

11 UIKit 0x22393e67 0x2231a000 + 499303

12 libdyld.dylib 0x1c94f50b 0x1c94c000 + 13579

위 로그파일에서 앱코드는 identifier 필드에 표시된 'full2016'인데 도시가 생략된 앱코드 확인부 및 앱코드 DB를 참조하여 확인할 수 있다.

위 로그파일의 헤더에서 예외타입이 SIGABRT로 기재되어 있으므로, 전술한 크래시 위치 정보와 함께 1차 크래시 리포트 그룹핑을 할 수 있다.

한편, 스택 트레이스 해싱 DB(209)를 참조하여 얻은 스택 트레이스 해시값은 다음과 같다. 만약 심볼화가 성공적으로 되지 않는다면, 이 해시값을 사용하여 대표 스택 트레이스와 매칭 여부를 확인할 것이다. 스택 트레이스 해시값은 해시 알고리즘을 통해 만든 고정된 길이의 데이터 값인데, 아래 해시값은 위 로그파일의 라인 0 내지 12를 해시 알고리즘의 하나인 MD5 알고리즘을 사용하여 만든 값이다.

6ea0ca5491f32bb8db110d15b12ae66d

물론 해시값없이 라인 0부터 라인 12까지 메모리 주소를 포함하는 라인을 그대로 사용하여 크래시 리포트 사이의 동일, 유사성을 비교할 수도 있겠으나, 그러한 경우 효율이 매우 저하될 것이다.

심볼화 DB(211)를 참조하여 성공적으로 심볼화한 스택 트레이스는 아래와 같다.

0 libsystem_kernel.dylib __pthread_kill (in libsystem_kernel.dylib)

1 libsystem_c.dylib abort (in libsystem_c.dylib)

2 libc++abi.dylib __cxa_demangle (in libc++abi.dylib)

3 libc++abi.dylib default_terminate_handler() (in libc++abi.dylib)

4 libobjc.A.dylib objc_terminate() (in libobjc.A.dylib)

5 libc++abi.dylib std::__terminate() (in libc++abi.dylib)

6 libc++abi.dylib __cxa_increment_exception_refcount (in libc++abi.dylib)

7 libobjc.A.dylib objc_begin_catch (in libobjc.A.dylib)

8 CoreFoundation CFSetGetValue (in CoreFoundation)

9 CoreFoundation CFRunLoopRunSpecific (in CoreFoundation)

10 GraphicsServices GSEventRunModal (in GraphicsServices)

11 UIKit stub helpers (in UIKit)

12 libdyld.dylib start (in libdyld.dylib)

스택 트레이스 라인 DB(214)은 각 크래시 그룹타입에 따른 라인들에 대한 정보, 대부분의 스택 트레이스에서 확인되는 범용적인 라인에 대한 정보, 런타임마다 달라지는 메쏘드에 대한 정보 등을 포함할 수 있다. 스택 트레이스 라인 DB(214)를 참조하면서 위 0번 라인부터 12번까지 차례로 시스템 관련 라인인지 여부를 확인해 내려간다. 그 결과, 모두 시스템 관련 라인이므로 0 내지 12번 라인이 모두 삭제되는데, 이 삭제 이후 남아있는 라인이 없게 되므로, 이들 시스템 관련 라인들을 회복하여야 한다. 회복시 라인 0, 1 및 12는 스택 트레이스 라인 DB(214)를 참조하면 대부분의 스택 트레이스에 포함되는 라인이기 때문에 회복시키지 않고 라인 2 내지 11만 회복시킬 수 있다. 이 라인 2 내지 11이 정제된 스택 트레이스로 추출되고, 이 중에서 최상위 라인인 라인 2가 루트 코즈 라인으로 추출된다. 그리고, 크래시 그룹 타입은 시스템 타입으로 분류되므로, 이들 정보로 2차 크래시 리포트 그룹핑을 진행한다. 1차 분류된 그룹내의 서브 그룹들의 대표 스택 트레이스 중에서, 크래시 그룹 타입과 추출된 루트 코즈 라인이 동일하고 라인 2 내지 11 중 7개 이상, 즉 70% 이상 동일한 라인을 가진 대표 스택 트레이스를 검색한다. 검색을 통해 매칭되는 대표 스택 트레이스가 있으면, 해당 서브 그룹에 추출된 정제된 스택 트레이스를 DB(207)에 저장하고, 매칭되는 대표 스택 트레이스가 없으면, 1차 분류된 그룹내에 새로운 서브 그룹의 대표 스택 트레이스로 DB(207)에 저장한다.

도 5는 앞서 설명한 1차 및 2차 크래시 리포트 그룹핑과, 대표 크래시 리포트 DB(207) 구조를 설명하는 도식도이다. 여기서, 1차 그룹핑은 설명 편의상 크래시 예외 타입으로만 분류되었다. 1차 그룹에는 NullReferenceException, IndexOutBoundException, IllgalStateException 등의 그룹으로 구분되어 있고, 각 1차 그룹에 복수개의 서브 그룹이 포함되어 있다. 예를 들어, IndexOutBoundException 그룹내에는 서브 그룹 D, E, F 등이 포함되어 있고, 각 서브그룹에는 대표 스택 트레이스를 포함하고 있다. 그룹핑을 해야 할 새로운 크래시 로그 파일을 수신하면, 크래시 위치, 예외 타입, 앱코드 등의 정보로 위 1차 그룹 중 어느 하나로 먼저 분류한 후, 추출된 정제된 스택 트레이스와 크래시 그룹 타입 등의 정보로 2차 분류를 진행한다.

본 발명의 실시예에 따른 크래시 리포트 그룹핑과 Apteligent의 그룹핑 결과를 비교하였다. 모바일 게임앱은 네이버용 레이븐이 사용되었고, 크래시 종류별로 사용된 로그 파일의 개수는 Java Exception 로그 80개, NDK Native 크래시 로그 200개, iOS Native 크래시 로그 200개로서 총 480개의 로그 파일이 테스트에 사용되었다. 크래시 리포트 그룹핑 결과, Apteligent는 406개 크래시 그룹으로 분류한데 반해, 본 발명의 실시예에 따른 그룹핑 방법은 282개의 크래시 그룹으로 분류하였다. 즉, Apteligent에 비하여 약 30% 정도 그룹 개수가 감소하는 효과를 보였다.

본 발명에 따른 상기 예시적인 방법들은 프로세서에 의해 실행되는 프로그램 명령들, 소프트웨어 모듈, 마이크로코드, 컴퓨터(정보 처리 기능을 갖는 장치를 모두 포함함)로 읽을 수 있는 기록 매체에 기록된 컴퓨터 프로그램 제품, 애플리케이션, 논리 회로들, 주문형 반도체, 또는 펌웨어 등 다양한 방식으로 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD, DVD, 자기 테이프, 하드 디스크, 플로피 디스크, 하드 디스크, 광데이터 저장 장치 등이 있으며, 이에 제한되는 것은 아니다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

이상의 설명은 본 발명을 예시적으로 설명한 것에 불과하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 본 발명의 기술적 사상에서 벗어나지 않는 범위에서 다양한 변형이 가능할 것이다.

따라서 본 발명의 명세서에 개시된 실시예들은 본 발명을 한정하는 것이 아니다. 본 발명의 범위는 아래의 특허청구범위에 의해 해석되어야 하며, 그와 균등한 범위 내에 있는 모든 기술도 본 발명의 범위에 포함되는 것으로 해석해야 할 것이다. 그리고, 본 발명의 청구항에 기재된 일부 단계들의 순서는 그 순서가 바뀌어 실시되어도 발명의 구현이 가능하다는 점을 이해할 수 있을 것이다.

10 사용자 단말기
20 크래시 리포트 그룹핑 서버
30 애플리케이션 서버
201 크래시 리포트 수신부
202 크래시 위치 확인부
203 크래시 예외 타입 확인부
204 스택 트레이스 라인 제거부 / 정제된 스택 트레이스 추출부
205 크래시 그룹타입 분류부
206 크래시 리포트 매칭부
207 대표 크래시 리포트 DB
208 스택 트레이스 해싱부
210 심볼화부

Claims (22)

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

Images