Core dump

컴퓨팅에서의 코어 덤프(core dump), 메모리 덤프(memory dump), 또는 시스템 덤프(system dump)는 보통 프로그램이 비정상적으로 종료(충돌)되는 때와 같은 특정 시점에 컴퓨터 프로그램에 기록된 작업 메모리로 구성된다. 실제로, 프로그램 카운터와 스택 포인터, 메모리 관리 정보, 기타 프로세서와 운영 체제 플래그 및 정보 등을 포함한 프로세서 레지스터같은 프로그램 상태의 중요 부분들이 대개 동시에 덤프 된다. 코어 덤프는 종종 컴퓨터 프로그램의 오류를 진단하고 디버깅하는 데 사용된다. 이 명칭은 1950년대부터 1970년대 랜덤 액세스 메모리의 주요 형태인 자기 코어 메모리에서 유래했다. 자기 코어 기술은 더 이상 쓰이지 않지만 그 명칭은 계속 쓰이고 있는 것이다. 많은 운영 체제에서 프로그램의 치명적인 오류가 자동으로 코어 덤프를 실행시키는데, 이를 "코어를 덤프한다"라고 한다. 이 말의 의미가 확장되어, 많은 경우에 프로그램 메모리의 기록이 발생하는지 여부에 관계없이 생기는 치명적인 오류를 의미하게 되었다. "코어 덤프", "메모리 덤프" 또는 그냥 "덤프"라고도 하는 이 용어는 추가적인 검사를 위해 많은 양의 원시 데이터를 저장하는 것을 나타내는 전문 용어가 되었다.

메모리 덤프 확인 방법

dd 명령어를 사용한 메모리 덤프

/dev/mem 또는 /dev/crash를 사용하여 메모리 덤프를 얻을 수 있습니다.

sudo dd if=/dev/mem of=/path/to/memory_dump.bin bs=1M

if=/dev/mem: 메모리 디바이스 파일.
of=/path/to/memory_dump.bin: 덤프 데이터를 저장할 파일.
bs=1M: 블록 크기를 1MB로 설정.

주의: 최신 Linux 커널에서는 보안 이유로 /dev/mem 접근이 제한되어 있을 수 있습니다.

proc 파일 시스템 접근

일부 메모리 관련 정보는 /proc 파일 시스템에서 얻을 수 있습니다.

cat /proc/<PID>/maps > /path/to/maps_dump.txt
cat /proc/<PID>/mem > /path/to/mem_dump.bin

기타 도구 모음

crash와 makedumpfile 도구를 사용한 메모리 덤프
gcore를 사용한 프로세스 메모리 덤프
volatility와 같은 포렌식 도구 사용

GDB GNU Debugger Intro

Segmentation fault가 발생한 후 core dump가 일어난다고 하였는데,

Core dump된 내용은 어디서 볼수 있나요?
dump된 내용을 어떻게 분석 할 수 있나요?
dump된 내용을 분석해서 어느 위치에서 segmentation fault가 발생 했는지 알 수 있는 방법은 무엇인가요?

dump파일은 죽을 때의 바이너리를 그대로 저장하고 있지요. 그래서 바이너리의 스택을 살펴보면 어떤 경로로, 어떤 함수에 어떤 파라미터가 들어와서 동작하다 죽었는지 알 수가 있는 것이죠.

Ubuntu example

## 덤프 크기 확인 ('core file size'의 초기값은 0이다)
$ ulimit -a

## 덤프 파일 크기의 제한을 풀어준다.
$ ulimit -c unlimited

## 덤프 크기 확인
$ ulimit -a

## !!
## 프로그램을 crash 시키면 동일 디렉토리에 코어 덤프 파일이 생성된다.
## !!

## abrt-cli 을 사용하여 확인.
## ...

## 또는 gdb를 사용하여 디버깅.
$ gdb [실행파일경로] [덤프파일경로]
gdb> backtrace
gdb> f 1

## 덤프 파일 크기를 0으로 다시 복구
$ ulimit -c 0

Favorite site

References

Gdb_gnu_debugger_intro.pdf ↩