Crash Dump

Linux Kernel은 panic이나 crash발생하게 되면 dump파일을 생성하여 문제가 발생하게 된 원인을 알 수 있도록 한다. oops message와 비슷하나, 보다 자세한 정보로 문제가 일어나게 된 요건등을 알수 있도록 보다 많은 정보를 제공 한다. 다음은 dump file들이 담고 있는 내용들이다.

1. General system information

2. Type of crash

3. Dump of the system buffer, which contains the latest messages printed via the kernel's printk function

4. CPU summary

5. Kernel stack trace leading up to the system PANIC

6. Disassembly of instructions before and after the instructions that caused the crash

다음은 dump file 분석에 사용되는 명령어들 이다.

1. stat : 현재까지 printk를 통해 print된 모든 메시지를 보여주기위한 commend

2. vtop : kernel과 application의 virtual-to-physical 맴핑 주소를 보여준다.

3. trace : 선택된 task또는 system에 운영중인 모든 task들의 back trace정보를 보여주는 commend.

4. dis : 기계어들을 보여주기 위한 commend.

dump 파일들은 주로 /var/log/dump디렉토리 아래 저장되는데, /etc/sysconfig/dump 파일안에 DUMPDIR값을 바꿈으로서 위치를 바꿀수 있다. 또한 dump file은 gigabytes를 넘을 수 있기 때문에 dump 파일이 저장될 위치의 공간이 충분한가를 먼저 파악해야 한다.

Patch

모든 linux kernel에서 Crash dump기능을 제공하지 않을 수 있다. 이에 자신의 kernel에서 해당 기능을 제공하는지는 make xconfig--> kernel hacking 메뉴를 통해 확일 할수 있다.

만약 위메뉴가 없다면 아래와 같은 방법으로 자신의 kernel읠 패치하여야 한다.

1. pd /usr/src/linux

2. download lkcdutils-6.x.x.patch.gz

3. gunzip lkcdutils-6.xx.patch.gz

4. patch -p1 -dry-run < /run/src/linux/lkcd-6.x.x.patch하여 이상없을으면 "-dry-run"을빼고 패치하면 된다.

Build

1.make xconfig

2. Kernel hacking->Crash dump support선택

3. make clean && make bzImage

4. 아래와 같은 명령을 하는 이유는 잘 모르겠음.....

cp arch/i386/boot/bzImage /boot/bzImage-2.x.x-lkcd

cp System.map /boot/System.map-2.x.x-lkcd

kerntypes는 kernel에 대한 정보를 보여주기 위한 파일이며,default는 /boot/Kerntypes

cp init/kerntypes.o /boot/Kerntypes-2.x.x-lkcd

rm /boot/System.map && ln -s /boot/System.map-2.x.x-lkcd System.map

rm /boot/Kerntypes && ln -s /boot/Kerntypes-2.x.x-lkcd Kerntypes

General Crash Dump Steps

1. dump되는 메시지의 level을 결정

8 : 모든 system 메모리

4 : 오직 사용된 메모리

2 : kernel 메모리

1 : Dump header

0 : Do nothing

2. dump에 필요한 partition size 결정.
예) system이 1GB이고, dump level은 8이면, 1GB의 partition size필요하다

3. create a symlink

ln -s /device/partition number

예) ln -s /dev/hda3 /dev/vmdump

4. /etc/sysconfig/dump에 DUMP_LEVEL을 8로 설정하다

5. Run /sbin/lkcd config

6. "dmesg"를 통해 lkcd 설정을 확인한다.

7. Enable sys-request

echo "1" > /proc/sys/kernel/sysrq

8. Trigger the dump

echo "c" > /proc/sysrq-trigger

DUMP_PANIC설정에 따라, system이 reboot되거나 shell로 돌아간다.

9. dump를 save하기 위해, run /sbin/lkcd save

dump는 partition에서 /var/log/dump/n으로 copy된다.

10. dump는 lcrash프로그램을 통해 display된다.

lcrash [System.map] [dump file] [kerntypes]하여 dump파일을 볼수있다.

위에서 마지막에 trace 수행을 하였는데, 이때 bash가 수행됨을 보여준다. 여기서 shell로 넘어가기 위해서는 echo "c" > /proc/sysrq-trigger 를 수행하면 된다.

View crash dump

아래는 kernel panic이 발생한 system을 예로 보여준다.

kernel panic이후 system은 reboot되었다.

위 메시지를 통해 null point가 jfs_mount의 offset 0x25에서 발생함을 알수 있다.

출처 : Debugging and Performance Tuning Chapter 14

Linux Trace Toolkit

LTT(Linux trace toolkit)은 process들의 운영서 발생하는 event,signal 등등의 정보를 나타내게 하는 toolkit이다. 다음은 toolkit이 수행이 일어나는 부분이다.

1.Kernel내에서 log을 위해 event가 발생할때

2. kernel에서 event를 buffer에 저장할때

3. signal발생할때

실행 방법 :1. 만약 kernel에 LTT patch되어 있지 않다면 "ltt-0.9.x-xxx.tar.bz2"다운받아 patch

(패치 방법)

1-1. /usr/src/linux

patch -p1 -dry-run < /usr/src/ltt/ltt-0.x.x/Patches/ltt-linux-2.x.x.patch 수행시 문제 없으면.

patch -p1 < /usr/src/ltt/ltt-0.x.x/Patches/ltt-linux-2.x.x.path수행하여 patch를 적용한다.

2. LTT patch를 위해서는 relayfs 설정도 필요하다.

3. make xconfig

4. "Kernel hacking"에서

"Kernel events tracing support"를 "y"로 선택

5. build

6. LTT package설정된것은 아래 명령을 통해 확인 가능하다.

rpm -qf /usr/bin/trace 하게 되면 -qt는 설치된 LTT package 버젼을 볼수 있다.

7. 설치된 이후, 아래와 같은 명령을 수행할 수 있게 된다.

• tracedaemon : user space daemon이며 kernel과 communcate한다.
• tracevisualizer는 그래픽 trace file viewer이다.

8. data를 collection하기 전에 relayfs file system을 반드시 mount해야 한다.

#mount -t relayfs nodev /mnt/relay

9. 여러 helper script들은 trace daemon을 시작하고 멈출 수 있다.

• trace [seconds] [filename] : trace 결과는 2개의 파일들에 저장된다.:filename.trace(trace data를 저장), filename.proc(/proc information을 저장)
  
• tracecpuid [seconds][filename] : trace와 동일하나, CPU identification 정보가 추가된다.
• traceu filename : trace daemon이 죽을때까지 activate된다. 그리고 정보는 trace와 같은 파일에 저장된다.

10. 수행 방법

tracer가 module로 build된다면, "modprobe tracer"명령을 수행해야 하며, 그렇지 않고 kernel에 build가 되어있다면 이 과정은 필요 없다.

이후 , "trace [시간] [ 파일 이름] ex) trace 20 trace1와같이 수행 하면 된다.

참고 : Debugging and Performance Tuning Chapter 9

Event log

Linux debugging에 있어 꼭 필요한 것이 syslog와 같은 even log utility이다. 하지만 android에는 syslog daemon이 없어 even log를 보는데 제한이 있으나 대신 /proc/kmsg를 통해 제공하여, 이런 역할을 대신한다.

이밖에 even log utilities

- evl_writek(), evlsend, evlview, evlnotify등이 있다.

출저 : Debugging and Performance Tuning Chapter 8.

Finding stack info

Powerppc의 경우 print_backtrace()라는 강력한 함수를 통해 호출 함수의 경로를 거슬러 올라갈수 있다. 하지만 ARM, MIPS등의 architecture에서는 지원 되지 않는다. 하지만, print_backtrace()가 stack의 정보를 통해 정보를 얻듯, 이와 비슷한 기능의 함수들이 있다.

backtrace와 backtrace_symbols 이다. 이들을 통해 좀더 효율적인 debugging이 이루어 질것이다.

참조 : http://linux.die.net/man/3/backtrace_symbols

Linux Kernel debugging tip

리눅스 debugging 방법은 크게 비파괴 방식과 파괴 방식으로 나눌수 있다.

비파괴 방식이란 코드 수정없이 debugging하는 것을 말하는데, strace,ltrace등이 있으며, 파괴식 방식이란 코드 수정을 하여 debugging하는 방식이 있는데, 대표로 printk등이 있다.

1. 비파괴 방식

1. strace

- 실행 방식 : strace 실행파일 이름 예) strace ls

- 역할 : progam 수행시 행해지는 system call들을 display하여, 어떤 일들이 내부에서 일어나는지를 알수 있게 한다.

2. ltrace

- 실행 방식 : ltrace 실행 파일 이름 예) ltrace ls

- 역할 : dynamic linker library에 들어있는 function들만 호출이 가능하다. ojbect file내부에 들어있는 function들 호출은 추적하지 못한다.

참조 : http://jh4hj.tistory.com/352

2. 파괴 방식

1. 1. rmalloc

• 역할 : malloc,calloc,realloc,free, strdup function등을 감싸는 macro이며, 동적 메모리 할당 이전과 이후에 특별한 문자열로 표시하며, 문제가 발생하면 file name과 line number출력하고 종료한다.
• 실행 방식 : package(rmalloc.tgz) 다운로드
  rmalloc.c를 -c 옵션과 함께 컴파일
  debugging원하는 code에 #define MALLOC_DEBUG추가, #include "rmalloc.h"추가, link시 rmalloc.o

참조 : http://jh4hj.tistory.com/351

2. MEMWATCH

• 역할 : rmalloc과 동일하다.
• 실행 방법 : memwatch를 다운받고 설치
  #include "memwatch.h" 추가
  gcc -DMEMWATCH -DMW_STDIO 하여 compile
  프로그램 수행하게 되면 memwatch.log와 같은 파일 생헝하게 된다.
  

3. 이밖에도 Electric Fence, YAMD등이 있는데, 이들은 application에는 적합할수 있으나, kernel debugging에는 적합하지 않는 것으로 보인다.