<< 캡쳐자료입니다>>
원문 출처 : http://blog.naver.com/dangtong76/140054144449
[정보] 초간단 CORE 파일 분석방법
오늘 턱시도 서비스하나가 반영이됐는데 해당 서비스가 특정패턴으로 수행될경우 턱시도 서버를 죽이는 현상일 발생했습니다.
그림에서 처럼 crt100n 이란 턱시도 서비스가 CRS102T 라는 서비스를수행 하려다가 뒤져버렸습니다.
호랑이는 죽어서 가죽을 남기고 프로세스는 죽어서 CORE 를 남깁니다.
The GNU Debugger(보통 GDB 라고 부릅니다) 라는 프로그램을 통해 CORE 파일을 분석해보기로 마음먹었습니다.
GDB 는 거의 대부분의 유닉스 서버에 다 깔려있습니다.
1단계 : CORE 파일의 정체를 파악
core 라는 이름만 가지고는 누가 죽어서 남긴 놈인지 알수가 없습니다. 그래서 file 이라는 명령을 통해 core
파일을 생산한 놈이 누구인지 확인을 해야 합니다.
보시다 시피 해당 core 파일은 08:54 분에 죽은 crt100n 이라는 프로세스가 남긴거네요 ㅋㅋ ^^
2단계 : GDB를 이용한 CORE 파일 분석
gdb사용법 : gdb 수행파일 CORE파일
ex) gdb ./crt100n ./core
아래를 보시면 먼저
Core was generated by `crt100n'.
Program terminated with signal 11, Segmentation fault.
crt100n 이라는 프로세스가 메모리 세그먼트 오류로 인해 죽었고 죽으면서의 마지막 한마디는 "11" 입니다. ^^ ㅋ
3단계 : 문제의 시점(죽은시점)에 무슨일을 했을까?
문제의 시점에 해당 프로세스가 수행한 일을 보기 위해 "where" 라는 gdb 명령어를 사용합니다. where 라고 치면
죽은시점에서스 함수 CALLSTACK(함수호출순서) 을 보여줍니다. 보는 방법은 자바와 마찬가지로 밑에서부터 위로
수행됐다고 보시면 됩니다.
죽은 원인은 "error accessing memory address 0x0: Invalid argument." 이고 해당 에러가 발생할때의 행동은
CRS105T -> CRS102T -> tpenqueue -> tmatmienter -> tmreattach -> _gp_shmat -> malloc -> _sscanf -> sigfillset
순으로 함수가 호출되었고 sigfillset 이란 함수를 수행하다가 죽었습니다. 왜냐면 제일마지막에 수행한 놈이니깐요.
여기서 잠깐 프로그램이 함수호출과정을 간단하게 살펴보겠습니다.
우리가 프로그램을 짜면 하나의 프로그램은 다음과 같이 구성되어 집니다
user define function(사용자 정의 함수) / application programming Interface (API) / standard library (STD library) / system call (OS 호출함수)
대부분의 프로그램의 호출 순서는 다음과 같습니다
패턴1 : 사용자정의함수 -> STD library -> system call
패턴2 : 사용자정의함수 -> API -> STD library -> OS호출함수
GDB 결과를 보시면 CRS105T 라는 프로그램에서 턱시도함수 tpenqueue (API) 를 호출합니다. 그리고 턱시도 함수는 우리가 학교다닐때배운 malloc 이라는
standard 라이브러리에 있는 함수를 호출합니다. 그리고 다시 malloc 이라는 함수는 _sscanf 라는 system call 함수를 호출합니다.
그래서 요약해보면 CRS105T -> CRS102T -> 턱시도함수 -> STD Library Function -> System call function 으로 순서가 정해집니다