Skip to content
Search

Core dump

lastmod 2025-01-08created 2016-02-2214 edits

In computing, a core dump, memory dump, or system dump consists of the recorded working memory of a computer program at a specific point in time, usually when the program terminates abnormally (crashes). In practice, other key parts of the program state are usually dumped at the same time, such as the processor registers, including the program counter and stack pointer, memory management information, and other processor and operating system flags and information. Core dumps are often used to diagnose and debug errors in computer programs. The name comes from magnetic core memory, the main form of random-access memory from the 1950s to the 1970s. Magnetic core technology is no longer used, but the name lives on. In many operating systems, a fatal error in a program automatically triggers a core dump, which is called "dumping core". By extension, the phrase has come to mean, in many cases, any fatal error, regardless of whether a record of the program memory is produced. The term "core dump", "memory dump", or simply "dump" has become jargon for saving a large amount of raw data for further examination.

Category

How to inspect memory dumps

Memory dump using the dd command

You can obtain a memory dump using /dev/mem or /dev/crash.

sudo dd if=/dev/mem of=/path/to/memory_dump.bin bs=1M
  • if=/dev/mem: the memory device file.
  • of=/path/to/memory_dump.bin: the file to save the dump data to.
  • bs=1M: sets the block size to 1MB.

Caution: recent Linux kernels may restrict access to /dev/mem for security reasons.

Accessing the proc file system

Some memory-related information can be obtained from the /proc file system.

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

Other tools

  • Memory dump using the crash and makedumpfile tools
  • Process memory dump using gcore
  • Using forensic tools such as volatility

GDB GNU Debugger Intro

I was told that a core dump happens after a segmentation fault occurs, so:

  • Where can I see the core-dumped contents?
  • How can I analyze the dumped contents?
  • How can I analyze the dumped contents to find out where the segmentation fault occurred?

The dump file stores the binary exactly as it was when it died. So by examining the binary's stack, you can find out through which path, and in which function with which parameters, it was running when it died.

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

See also

Favorite site

References


  1. Gdb_gnu_debugger_intro.pdf ↩

author Zer0 sitemap