Post-mortem Debug and Software Failure Analysis on Symbian OS

Mobile device가 crash되었을 때 이에 대한 원인을 재현하는 것은 쉬운 일이 아니다. 때문에 문제가 발생한 상황에 대한 자세한 정보를 어딘가에 남길 수 있다면 매우 유용할 것이다.

(최근 우리 회사에서도 이에 대한 노력 및 과제가 진행이 되고 있다.)

주요 내용을 소개하면 아래와 같다.

In brief Mobile Crash works so when a software failure happens on the smartphone, the debug agent installed to the phone can catch the software failure, collect relevant data of the panicked software component including panicked thread stack, run time loaded binary modules list, and CPU registers.

(Mobile Crash가 무엇이고 어떻게 동작하는지 간략하게 소개한다.)

With only emulators, not every application can be completely implemented. Some applications need to use the communication channel such as Bluetooth or need to access the GSM netowork to send or receive message.

(Emulator가 아닌 target device에서 수행을 해야하는 경우가 발생을 한다. 이경우에는 crash상황에서의 관련 정보를 획득하는 방안이 필요할 것이다.)

It installs a debugging agent application to the target hardware to establish a communication channel (can be USB or Bluetooth) with the IDE and pass commands and parameters between them. When debugging an application, a copy of executables and resources are first transferred to the target hardware.

(어떻게 동작할 수 있는지에 대해서 Metrowerk사의 사례를 소개한다.)

The end users are often unable to record the exact steps before certain software component fails or panics. Consequently, it makes difficult for developers to reproduce and fix the bug. Sometimes it needs lots of communication between the end users and developers to try to reproduce the failure situation, and fixing one bug requires much time and efforts from both sides. Hence, the smartphones under testing need to have a debugging utility to capture software failures, and to collect information of the panicked component for the purpose that the bug can be located and fixed by analyzing the collected data.

(자료에서 소개하는 기능에 의한 효율이 크다는 것을 강조하는 설명이다.)

To design the core, first the necessary data for analyzing panics must be defined. Developers need at least have the information of the panicked software module, panic category and panic ID to know which component has failed.

(core 디자인 단계부터 필요한 info.를 남길 수 있도록 고려해야한다는 설명이다.)

자료에서는 Table1에서 OS panic이 발생하였을 때 수집되어야 할 항목들을 나열하는데 이는 생략한다.

(사실 자료의 핵심 내용일 듯 하지만 제대로 이해를 하지 못하였다.ㅡ.ㅡ;;)

panic 상황에서 info.를 어떻게 남길 수 있는가에 대해서도 자세하게 설명을 한다. SMS, USB, LAN 등 여러가지 방법이 있을 듯 하다.

In addition to the decoding application, Mobile Crash decoding server needs to have the database set up to store panic information after panic have been decoded successfully. Statistics can be calculated by making queries to database. .For browsing the panic info and viewing the statistic graphics, the web service is held in the same server.

(수집된 data 를 저장한 DB server가 있으면 유용할 것이라는 설명이다.)

There are two main groups of panics defined, which are the Symbian user panic and the Symbian kernel panic. These are defined to identify where the panic is raised, either from a user side thread or a kernel side thread.

(문제가 발생하였을 때 kernel에서 발생한 panic인지 혹은 user process에서 발생한 panic인지 구분하여 리포트하는 것이 필요하다고 설명을한다. 문제의 위치를 확인하는 것이 중요하기에 이는 실무적으로도 매우 중요할 듯 하다. 실제 개발팀에서는 문제가 발생하였을 때 그 문제에 대한 담당파트가 어디인지에 대해서 갑론을박식의 많은 시간을 소요하는 경우가 있다.)