2016년 3월 10일 (목) 19:05 기준 최신판

Overview

본 자료는 JTAG이나 gdb와 같이 Application을 디버깅하기 위한 별도의 연결과정이 필요없는 Software Debugging Solution인 Live Recorder의 사용 방법을 정리한 문서입니다

Live Recorder는 Linux Application의 수행정보를 실시간으로 저장하는 솔루션이며, 저장된 정보는 UndoDB를 통해서 디버깅에 활용할 수 있습니다.

본 문서를 통해 Live Recorder를 이용해서 recording data를 얻는 방법과 Undodb를 이용해서 복원 및 분석하는 방법을 이해할 수 있습니다.

본 문서에서는 segmentation fault을 일으키는 간단한 application 코드를 이용해서 실습합니다. 해당 예제를 컴파일 한 후 실행하면 아래와 같이 segmentation fault를 발생시킵니다.

 해당 소스는 아래와 같습니다.

사용 환경

Live Recorder는 application을 디버깅하기 위해서 별도의 연결작업이 필요하지 않습니다. 그렇기 때문에 recording data를 확보하기 위해서는 추가 작업이 필요합니다. 이는 application의 일부 소스를 수정해야 recording data를 확보할 수 있습니다.

준비 사항

Debugging Symbol

C/C++ 소스 레벨로 디버깅을 위해서는 symbol 정보가 필요합니다. Symbol 정보는 컴파일 시에 option에 의해 결정됩니다.

일반적으로 symbol 정보가 정상적으로 만들어지는 경우 makefile 내의 CFLAG 옵션에 –g 가 포함이 되어 있습니다. Symbol정보가 정상적으로 만들어진 경우 디버깅 시 C/C++ 소스 레벨로 디버깅이 가능합니다.

Symbol 파일이 정상적으로 만들어졌는지 확인하고자 할 때는 linux 명령어 중 file/readelf 명령어를 이용해서 확인 가능합니다.

Live Recorder 사용을 위한 Header 파일과 Library 파일

Live Recorder를 이용하기 위해서는 header file(undolr.h)과 library(libundolr_xxx.a 혹은 libundolr_xxx.so)가 필요합니다.

Live recorder를 이용해서 recording을 하기 위해서는 특정 함수를 이용합니다. 해당 함수는 undolr.h 파일에서 확인할 수 있습니다.

이 중에서 undolr_recording_start(), undolr_save() 그리고 undolr_save_on_termination() 함수를 가장 많이 활용합니다.

Porting

 Live Recorder를 사용해서 recording data를 확보하는 방법은 두 가지가 있습니다.

 첫 번째로 마지막에 저장될 함수 위치를 아는 경우와 두 번째로 exception 발생으로 인한 비정상적인 종료로 인해 함수 위치를 모를 경우 이렇게 두 가지로 나뉠 수 있습니다.

마지막에 저장될 함수 위치를 아는 경우

 1. 먼저 디버깅할 소스에 live recorder의 함수를 사용하기 위해 header file을 include합니다.
     해당 header file이 동일한 폴더에 있으면 현재 폴더 기분으로 입력하면 되고, 다른 경로에 있으면 해당 경로를 추가해서 include하면 됩니다.

2. Recording을 시작하기 위해서는 undolr_recording_start() 함수를 원하는 위치에 입력합니다. 해당 코드가 실행 후에 recording을 시작합니다. 일반적으로는 main함수 진입부터 입력하면 됩니다.


3. Recording을 중단하고 싶은 위치에 undolr_save() 함수를 이용합니다.


4. 전체 코드를 정리하면 아래와 같습니다. Main의 마지막 코드까지 recording을 하는 것이 아니라 중간의 일부 코드까지만 recording을 합니다.


5. 컴파일 할 때 live recorder library와 함께 컴파일을 합니다. 정상적으로 컴파일이 되면 실행파일이 생성됩니다.



6. 해당 실행 파일을 실행하면 아래와 같이 recording 파일이 생성됩니다.

Exception에 의해서 정확한 위치를 모를 경우

일반적으로 exception이 발생하게 될 경우 해당 application이 어디서 문제가 발생해서 죽는지 알 수 없습니다. 이런 경우 undolr_save() 함수를 통해서 recording된 data를 파일로 저장하기가 쉽지 않습니다. 이와 같이 save할 위치를 정확히 알 수 없는 경우에는 undolr_recording_start() 함수 후에 undolr_save_on_termination() 함수를 사용하면 application이 죽는 직후 recording data를 자동으로 저장시켜 줍니다.

1. Undolr_recording_start() 함수 아래에 undolr_save_on_termination()함수를 추가합니다.
   해당 함수가 실행 후 비정상 종료가 되면 자동으로 recording file로 저장합니다.


2. 다시 컴파일 후 실행 파일을 실행합니다.



3. 해당 application은 segmentation fault를 발생시키기 때문에 문제가 되는 위치를 마지막으로 exception_termi.undo 파일로 저장됩니다.

Loading

Recording data를 복원하는 방법은 두가지 방법을 제공합니다.

Temimal을 이용한 commanda 방식과 Eclipse기반의 GUI를 통해 복원이 가능합니다.

두 방식 모두 undodb-gdb를 사용하며, 복원 명령어는 undodb-gdb --undodb-load <filename> 명령어를 통해서 로드합니다.

Teminal의 command 방식으로 복원하는 방법

마지막에 저장될 함수 위치를 아는 경우의 recording data

앞에서 undolr_save()함수를 통해서 특정 위치까지 recording한 exception.undo 파일을 로딩한 후 저장된 위치를 확인해 봅니다.

1. 로딩하는 명령어를 이용해서 recording file을 로딩합니다.


2. 로딩이 제대로 되면 continue 명령을 통해 recording data를 한번 실행해야 합니다.
   Cont를 하면 마지막까지 저장된 recording data를 확인할 수 있습니다.


3. Backtrace 명령을 통해 해당 call stack 정보를 확인합니다.
   마지막에 저장된 함수는 undolr_save() 함수인 것을 확인할 수 있습니다.

Undolr_save()함수를 이용해서 recording을 하게 되면 무조건 마지막 함수는 undolr_save()함수가 되며, undolr_recording_start()함수부터 undolr_save()함수까지의 data만 recording이 됩니다.

정확한 위치를 모를 경우의 recording data

Application 종료가 되는 위치를 모를 경우에는 위에서 undolr_save_on_termination() 함수를 이용했습니다. 해당 함수를 이용하면 해당 application이 exception이 발생해서 어느 위치에서 죽든 죽는 위치를 마지막으로 recording 파일이 생성됩니다.

 Undolr_save_on_termination()함수를 이용해서 저장한 exception_termi.undo 파일을 로딩합니다.

1. 로딩하는 명령어를 이용해서 recording 파일을 로딩합니다.


2. 로딩이 완료 후 continue 명령어를 통해 recording data를 실행해 줍니다.


3. Backtrace 명령을 통해 마지막에 수행된 코드를 확인합니다. 아래 에서는 main에서 memcpy관련 함수를 수행한 것을 확인할 수 있습니다.


4. Main 함수의 정보를 보면 exception_lr.c 파일의 48 line에서 호출된 것을 볼 수 있는데 list명령을 통해서 코드 정보를 확인합니다.
   memcpy 함수인 것을 확인할 수 있으며, 해당 함수 수행 중 segmentation fault가 발생한 것을 확인할 수 있습니다.

Eclipse GUI를 통해 복원하는 방법

Eclipse를 이용해 복원하는 방법은 recording data를 실제 target에 로딩해서 복원하는 방법으로 remote connection을 이용해야 합니다.

1)     Recording를 로딩하기 위한 script를 작성합니다. 해당 script에는 복원할 때 사용하는 undodb-server를 통해 복원이 이루어지며, eclipse는 복원 이후 디버깅을 위해 remote 접속을 하게 됩니다.

Script에는 복원에 필요한 recording file를 명시하면 됩니다.

2)     Eclipse에서 remote connection을 위한 환경 설정을 진행합니다. RUN메뉴 내의 Debug Configuration으로 진입합니다.

3)     Debugger 내의 Gdbserver Settings 탭으로 이동한 후 위에서 작성한 script의 경로를 입력합니다.

4)     설정을 완료한 후 설정한 remote를 선택해서 recoding data의 복원 및 디버깅을 시도합니다.

5)     현재 상태는 target의 application을 실행한 것이 아니라 live recorder로 확보한 recording data를 가상으로 실행 및 복원한 상태입니다.

UndoDB를 이용하기 때문에 문제 분석을 위해 reverse 기능 사용이 가능합니다.

결론

Application이 동작 중에 갑자기 죽는 문제가 발생하면 디버깅하기 어렵습니다. 특히 field 테스트나 양산 테스트 진행 중 간헐적으로 발생하는 문제의 경우는 더욱더 힘듭니다. 이런 경우 Live Recorder를 포팅한 후 문제가 발생할 경우 recording data를 확보하게 되면 어디서 어떤 원인인으로 문제가 발생했는지 application 실행 상황을 그대로 재현할 수 있습니다.

디버깅 시간 및 개발 기간을 단축시키는 것은 비용 절감에 큰 도움이 됩니다.