코어 덤프

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

코어 덤프는 프로그램 오류 분석 및 디버깅을 위해 프로세스의 메모리 내용을 기록한 파일이다. 자기 코어 메모리에서 유래되었으며, 초기에는 종이에 8진법 또는 16진법 숫자로 출력되었으나, 기술 발전으로 파일 형태로 저장되었다. 현대 운영 체제에서 코어 덤프는 프로세서 레지스터 값 등과 함께 특정 프로세스 또는 주소 공간의 메모리 이미지를 포함하며, 디버깅 도구를 통해 분석된다. 코어 덤프는 오류 분석, 정보 복구, 임베디드 시스템 디버깅, 고가용성 시스템 구축 등 다양한 분야에서 활용되며, 보안상 민감한 정보를 포함할 수 있어 취급에 주의가 필요하다.

더 읽어볼만한 페이지

디버깅 - 스택 추적
스택 추적은 프로그램 실행 중 함수 호출 기록을 추적하여 오류 발생 시 디버깅 및 문제 해결에 필수적인 도구로, 호출 스택의 스택 프레임을 분석하여 프로그램 실행 경로를 파악하고 오류 원인을 추적하며 프로그램 안정성을 향상시키는 기술이다.
디버깅 - 메모리 디버거
메모리 디버거는 메모리 접근, 할당, 해제를 모니터링하여 메모리 오류를 찾아내고 소프트웨어의 신뢰성을 높이는 도구이다.
컴퓨터 오류 - 블루스크린
블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다.
컴퓨터 오류 - 글리치
글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다.

코어 덤프
일반 정보
다른 이름	메모리 덤프, 시스템 덤프
영어	Core dump, Memory dump, System dump
설명	프로세스의 메모리 내용을 기록하는 것
용도	디버깅 및 사후 분석
기술적 세부 사항
포함 정보	프로세스의 메모리 이미지 프로세서 레지스터 상태 프로그램 카운터 및 스택 포인터 운영 체제 관련 정보
트리거 조건	프로그램 충돌 (세그멘테이션 오류, 잘못된 명령어) 운영 체제 또는 사용자의 요청
저장 위치	파일 시스템의 특정 위치 (운영 체제에 따라 다름)
파일 형식	운영 체제에 따라 다름 (예: ELF, Mach-O)
활용
디버깅	충돌 원인 분석, 메모리 누수 탐지, 프로그램 상태 조사
사후 분석	시스템 장애 원인 분석, 보안 취약점 분석
운영 체제별 처리
유닉스 계열 시스템	일반적으로 "core"라는 이름의 파일로 저장
윈도우	메모리 덤프 파일을 생성하도록 구성 가능
기타
보안 고려 사항	코어 덤프에 민감한 정보가 포함될 수 있으므로 접근 제한 필요

2. 역사적 배경

"코어 덤프"라는 용어는 1950년대부터 1970년대까지 램(RAM)의 주된 형태였던 자기 코어 메모리에서 유래되었다.^[5]^[6] 자기 코어 기술이 구식이 된 지 오래되었지만, 이름은 여전히 남아있다. "메모리 덤프" 또는 그냥 "덤프"라고도 불리는 이 용어는 추가적인 검사를 위해 많은 양의 원시 데이터를 저장하는 것을 의미한다.

2. 1. 초기 형태

초창기 코어 덤프는 메모리 내용을 종이에 출력한 것이었는데,^[7] 보통 8진수 또는 16진수 ("16진 덤프") 숫자의 열로 정렬되어 있었다. 때로는 기계어 명령어, 텍스트 문자열, 10진수 또는 부동소수점 숫자로 해석된 내용이 함께 제공되기도 했다 (디스어셈블러 참고).

운영 체제가 등장하고 큰 데이터 파일을 처리할 수 있게 되기 전에는, 코어 덤프는 일반적으로 8진수이나 16진수(헥스 덤프)로 표기되었고, 경우에 따라서는 이를 기계어 명령어, ASCII 문자열, 10진수나 부동 소수점으로 번역한 것도 함께 표시되었다.

2. 2. 발전 과정

디스크 운영 체제와 대용량 데이터 파일을 기록할 수 있는 기술이 등장하기 전까지, 코어 덤프는 일반적으로 8진수 또는 16진수 ("16진수 덤프") 형태로 종이에 출력되었다.^[28] 때로는 기계 명령어, 텍스트 문자열, 10진수나 부동소수점 숫자로 해석된 내용이 함께 제공되기도 했다. (디스어셈블러 참조).

최신 운영 체제에서 "코어 덤프"는 프로세서 레지스터 값과 같은 다른 정보와 함께, 특정 프로세스의 메모리 이미지, 또는 해당 프로세스 주소 공간의 부분적 메모리 이미지를 지닌 파일이다. 이러한 파일은 텍스트로 인쇄하거나 볼 수 있고, objdump와 같은 전문 도구를 사용하여 분석할 수 있다. 근래의 코어 덤프 파일 및 오류 메시지는 일반적으로 16진수 인코딩을 사용하는데, 이는 16진수가 10진수나 8진수 표현보다 프로그래머에게 더 익숙하기 때문이다.

메모리 크기가 증가하고 사후 분석 유틸리티가 개발됨에 따라 덤프는 테이프나 디스크와 같은 자기 매체에 기록되었다. 현대 운영 체제는 관련 메모리의 내용만 표시하는 대신, 일반적으로 충돌한 프로세스에 속한 메모리 이미지 또는 해당 프로세스와 관련된 주소 공간의 일부 메모리 이미지, 그리고 프로세서 레지스터, 프로그램 카운터, 시스템 플래그의 값 및 충돌의 근본 원인을 파악하는 데 유용한 기타 정보가 포함된 파일을 생성한다.

이러한 파일은 텍스트로 보거나 인쇄하거나 유닉스 및 유닉스 계열 운영 체제에서는 elfdump, 리눅스에서는 objdump 및 kdump, IBM z/OS에서는 IPCS (대화형 문제 제어 시스템),^[8] IBM z/VM에서는 DVF (덤프 보기 기능), 마이크로소프트 윈도우에서는 WinDbg, Valgrind 또는 기타 디버거와 같은 특수 도구를 사용하여 분석할 수 있다.

운영 체제(OS)가 등장하고 큰 데이터 파일을 처리할 수 있게 되면서, 코어 덤프는 메모리 내용을 종이에 인쇄하는 것에서 특정 프로세스의 주소 공간 일부 또는 전체 메모리 이미지를 저장한 파일이 되었다. 이 파일에는 레지스터 값 등의 정보도 함께 저장되며, 적절한 도구를 사용하면 예전의 종이 코어 덤프처럼 사람이 읽을 수 있는 형식으로 참조할 수 있다.

3. 코어 덤프의 사용

코어 덤프는 프로그램의 버그를 식별하는 데 자주 사용된다. 고급 프로그래밍 언어에서는 컴파일러에 의해 기계어 명령 시퀀스가 생성된다. 컴파일 시 오류가 발생하지 않더라도 실행 시 잘못된 메모리 접근 등의 오류가 발생하는 경우가 많으며, 이 때 코어 덤프가 생성된다. 이러한 오류는 데이터 양을 작게 예상하여 발생하는 버퍼 오버플로우, 초기화되지 않은 변수를 사용한 널 포인터 접근 등이 원인이다. `kill -3` 또는 `gcore` 명령어를 사용하여 수동으로 코어 덤프를 생성할 수도 있다. 프로세스를 종료하기 전에 `gcore` 명령어에 프로세스 ID를 지정하면 해당 프로세스의 코어 덤프를 얻을 수 있다.

많은 운영 체제에서 프로그램 내의 치명적인 오류는 자동으로 코어 덤프를 발생시킨다. 코어 덤프는 특정 메모리 영역의 내용을 그대로 저장하고 있어, 어셈블리 언어나 메모리 사용에 제한이 없는 C 언어 등에서 발생하기 쉬운 포인터 오류(포인터 손상) 상태를 확인하는 데 적합하다. 이러한 버그는 소스 수준의 디버거로는 유효한 정보를 제공받기 어려운 경우가 많다.

디버거는 가능하다면 심볼 테이블을 사용하여 덤프를 번역하고, 변수명을 심볼로 표시하거나 해당하는 소스 코드를 표시할 수 있다. 덤프 분석기라는 특수한 도구도 존재한다. 최근 유닉스 계열 운영 체제에서는 GNU Binutils의 BFD 라이브러리를 사용하여 코어 덤프 파일을 읽을 수 있으며, GNU 디버거(gdb) 등이 이 라이브러리를 사용한다. BFD 라이브러리는 메모리 주소를 지정하면 해당 주소에 해당하는 코어 덤프 내의 원시 데이터를 반환할 뿐, 변수나 데이터 구조에 대한 정보는 가지고 있지 않다. 따라서 이 라이브러리를 이용하는 측에서 변수의 주소나 데이터 구조를 파악하고, 대상 프로그램의 심볼 테이블 등을 사용하여 디버깅해야 한다.

코어 덤프는 특정 시점(`gcore` 명령어 등)에 저장해두고 나중에 해당 상태로 되돌리는 데 사용될 수 있다. 고가용성 시스템에서는 이러한 코어 덤프 파일을 프로세서 간에 전송하여 고가용성을 실현하기도 한다. 이 기법은 GNU Emacs나 Perl과 같이 시작 비용이 매우 큰 소프트웨어에서도 이용된다. 미리 컴파일된 헤더 기술에서는 컴파일러가 헤더 파일을 처리하는 시점에 코어 덤프를 생성하여 헤더 파일 처리 시간을 절약하기도 한다.

코어 덤프는 생성 시점의 메모리 내용을 그대로 출력하므로, 보안상 민감한 정보를 포함할 수 있다. 따라서 신뢰할 수 없는 제3자에게 접근을 허용하지 않는 등 취급에 주의해야 한다.

3. 1. 디버깅 보조

초기 독립형 또는 일괄 처리 시스템에서 코어 덤프는 사용자가 (매우 비싼) 컴퓨팅 시설을 독점하지 않고도 프로그램을 디버깅할 수 있게 하였다. 또한 인쇄물은 전면 패널 스위치와 표시등을 사용하여 디버깅하는 것보다 더 편리했다.

시분할, 일괄 처리 또는 서버 시스템과 같은 공유 컴퓨터에서 코어 덤프를 사용하면 운영 체제를 오프라인으로 디버깅할 수 있으므로 시스템을 즉시 다시 작동시킬 수 있었다.

코어 덤프를 사용하면 사용자가 충돌을 나중에 또는 원격으로 분석하거나 다른 충돌과 비교하기 위해 저장할 수 있다. 임베디드 시스템의 경우 컴퓨터 자체에서 디버깅을 지원하는 것이 비현실적일 수 있으므로 덤프 분석은 다른 컴퓨터에서 수행될 수 있다. 초기 버전의 유닉스와 같은 일부 운영 체제는 실행 중인 프로세스에 디버거를 연결하는 것을 지원하지 않았으므로, 프로세스의 메모리 내용을 디버거에서 실행하려면 코어 덤프가 필요했다.

코어 덤프는 동적 메모리 할당 중에 해제된 데이터를 캡처하는 데 사용할 수 있으므로, 더 이상 실행되지 않는 프로그램에서 정보를 검색하는 데 사용할 수 있다. 대화형 디버거가 없는 경우, 꼼꼼한 프로그래머가 코어 덤프를 사용하여 직접 검사를 통해 오류를 확인할 수 있다.

3. 2. 오류 분석 및 비교

코어 덤프를 사용하면 사용자가 충돌을 나중에 분석하거나, 원격으로 분석하거나, 다른 충돌과 비교하기 위해 저장할 수 있다.^[1] 임베디드 시스템의 경우 컴퓨터 자체에서 디버깅을 지원하는 것이 비현실적일 수 있으므로 덤프 분석은 다른 컴퓨터에서 수행될 수 있다.^[1] 초기 버전의 유닉스와 같은 일부 운영 체제는 실행 중인 프로세스에 디버거를 연결하는 것을 지원하지 않았으므로 프로세스의 메모리 내용을 디버거에서 실행하려면 코어 덤프가 필요했다.^[1]

코어 덤프는 특정 상황에서 유용한 디버깅 도구가 될 수 있다.^[1] 초기 스탠드얼론 시스템이나 일괄 처리 시스템에서는 코어 덤프를 사용하여 사용자가 매우 비싼 컴퓨터 자원을 독점하지 않고 프로그램을 디버깅할 수 있었다.^[1] 또한, 스위치와 라이트를 사용하여 디버깅하는 것보다 프린트 아웃이 편리했다.^[1] 시분할이나 일괄 처리, 서버 기능을 겸하는 시스템에서는 코어 덤프를 사용하여 OS의 오프라인 디버깅이 가능해졌으며, 시스템은 즉시 정상적인 작업으로 돌아갈 수 있었다.^[1] 코어 덤프는 나중에 분석하거나 다른 코어 덤프와 비교 검토할 수 있었다.^[1]

3. 3. 임베디드 시스템

임베디드 시스템은 컴퓨터 자체에서 디버깅을 지원하기 어렵기 때문에, 다른 컴퓨터에서 코어 덤프 파일을 분석하여 문제를 해결한다.^[4]

3. 4. 정보 복구

코어 덤프는 동적 메모리 할당 과정에서 해제된 데이터를 캡처할 수 있으므로, 더 이상 실행되지 않는 프로그램에서 정보를 복구하는 데 사용될 수 있다. 상호작용 디버거가 없는 경우, 프로그래머는 코어 덤프를 직접 검사하여 오류를 판별할 수 있다.

4. 작동 방식 및 분석

코어 덤프는 일반적으로 덤프된 프로세스의 주소 공간 내용을 포함한다. 초창기 코어 덤프는 메모리 내용을 종이에 출력한 것이었는데,^[7] 보통 8진법 또는 16진법 숫자의 열로 정렬되어 있었다("16진 덤프"). 때로는 기계어 명령어, 텍스트 문자열, 10진수 또는 부동소수점 숫자로 해석된 내용이 함께 제공되기도 했다 (디스어셈블러 참고).

현대 운영 체제는 관련 메모리의 내용만 표시하는 대신, 일반적으로 충돌한 프로세스에 속한 메모리 이미지 또는 해당 프로세스와 관련된 주소 공간의 일부 메모리 이미지, 그리고 프로세서 레지스터, 프로그램 카운터, 시스템 플래그의 값 및 충돌의 근본 원인을 파악하는 데 유용한 기타 정보가 포함된 파일을 생성한다.

코어 덤프는 특정 시점에서 저장해두고 나중에 해당 상태로 되돌리는 데 사용하거나, 고가용성 시스템에서 프로세서 간에 코어 덤프 파일을 전송하여 고가용성을 실현하는 데 사용하기도 한다. GNU Emacs나 Perl과 같이 시작 시 비용이 매우 높은 소프트웨어에서도 이 기법이 이용된다. 또한 미리 컴파일된 헤더 기술에서는 컴파일러가 헤더 파일을 처리하는 시점에서 코어 덤프를 생성하여 헤더 파일 처리 시간을 절약하기도 한다.

코어 덤프는 생성 시의 메모리 내용을 그대로 출력하므로, 보안상 민감한 정보를 포함할 수 있다. 따라서 신뢰할 수 없는 제3자에게 접근시키지 않는 등 취급에 주의해야 한다. 사용자 프로세스의 코어 덤프는 소유자 외에는 접근할 수 없도록 커널이 권한을 설정하는 경우가 많다. setuid 또는 setgid 비트에 의해 실효 UID 또는 실효 GID를 변경한 프로세스에서는 실 UID 또는 실 GID 사용자로부터의 엿보기를 방지하기 위해 코어 덤프를 생성하지 않는 것이 일반적이다. 커널 코어 덤프에는 OS를 사용하던 모든 사용자의 정보가 포함되므로, 소유자는 일반적으로 슈퍼 유저로 설정된다. 분석을 위해 코어 덤프를 외부로 반출하는 경우에는 반출처의 신뢰성을 확인하거나 코어 덤프 암호화 등 보안 대책을 실시하는 것이 바람직하다.

4. 1. 데이터 구조

운영 체제에 따라 덤프는 메모리 영역의 해석을 돕기 위한 여러 데이터 구조를 가질 수도 있다. 이러한 시스템에서 성공적인 해석을 위해서는 덤프를 해석하려는 프로그램 또는 사용자가 프로그램의 메모리 사용 구조를 이해해야 한다.

4. 2. 분석 도구

디버거는 심볼 테이블을 사용하여 변수를 확인하고 소스 코드를 보여줌으로써 프로그래머가 덤프 해석을 돕는다. 심볼 테이블을 사용할 수 없는 경우에도 문제의 원인을 파악할 수 있는 경우가 있다. 덤프 분석기는 덤프 분석에 특화된 도구이다. GNU binutils의 objdump와 같은 도구가 널리 사용된다.

최신 유닉스 계열 운영 체제에서 관리자와 프로그래머는 GNU Binutils 바이너리 파일 디스크립터 라이브러리(BFD), GNU 디버거(GDB), 그리고 objdump를 사용하여 코어 덤프 파일을 읽고 분석할 수 있다. 이 라이브러리는 코어 덤프의 메모리 영역에서 주어진 주소에 대한 원시 데이터를 제공한다. 이 라이브러리는 해당 메모리 영역의 변수나 데이터 구조를 인식하지 못하기 때문에, 코어 덤프를 읽을 때 라이브러리를 사용하는 응용 프로그램이 변수의 주소와 데이터 구조 자체의 레이아웃을 결정해야 한다. 디버깅 중인 프로그램의 심볼 테이블을 사용하는 것이 그 예이다.

리눅스 시스템의 크래시 덤프 분석가들은 kdump 또는 리눅스 커널 충돌 덤프(LKCD)를 사용할 수 있다.^[29]

4. 3. 리눅스 시스템 분석 도구

리눅스 시스템의 크래시 덤프 분석가는 kdump 또는 Linux 커널 크래시 덤프(LKCD)를 사용할 수 있다.^[29]

5. 코어 덤프 파일 형식

현대 운영 체제는 코어 덤프 파일을 생성할 때, 충돌한 프로세스의 메모리 이미지뿐만 아니라 프로세서 레지스터, 프로그램 카운터, 시스템 플래그 값 등 디버깅에 유용한 추가 정보를 함께 저장한다. 이러한 파일들은 텍스트 형태로 보거나 인쇄할 수 있으며, 특수 도구를 사용하여 분석할 수 있다.

유닉스 및 유닉스 계열 운영 체제에서는 `elfdump`, 리눅스에서는 `objdump` 및 `kdump`를 사용한다. IBM z/OS에서는 IPCS (대화형 문제 제어 시스템)^[8], IBM z/VM에서는 DVF (덤프 보기 기능), 마이크로소프트 윈도우에서는 WinDbg, Valgrind 또는 기타 디버거를 사용하여 분석할 수 있다.

일부 운영 체제에서는 응용 프로그램이나 운영자가 전체 저장 공간 대신 선택된 저장 블록의 스냅샷을 요청할 수도 있다.

초기 운영 체제에서는 프로세스의 주소 공간이 연속적이었기 때문에 코어 덤프 파일은 단순히 주소 순서대로 바이트를 나열하는 형태였다. 그러나 최근 운영 체제에서는 프로세스의 주소 공간에 사용하지 않는 부분이 존재하므로, 이를 표현하기 위해 파일 형식이 복잡해졌다. 또한 덤프 수집 시점의 프로그램 상태 등의 정보도 저장된다.

유닉스 계열 시스템에서는 코어 덤프가 메모리 이미지 재현을 용이하게 하기 위해 실행 파일의 파일 포맷을 사용한다. 구체적인 형식은 하위 섹션에서 자세히 설명한다.

5. 1. 유닉스 계열

유닉스 계열 시스템에서 코어 덤프는 메모리 이미지 재현을 용이하게 하기 위해 실행 파일의 파일 포맷을 사용한다.

구형 유닉스 버전에서는 a.out 형식이 사용되었다.
최신 리눅스, System V, Solaris, BSD 시스템에서는 ELF 형식이 사용된다.
macOS에서는 Mach-O 형식이 사용된다.

솔라리스(Solaris) 8부터 시스템 유틸리티 `coreadm`을 사용하여 코어 파일의 이름과 위치를 구성할 수 있다. 사용자 프로세스의 덤프는 전통적으로 `core`로 생성된다. 리눅스에서는 리눅스 커널 메인라인의 버전 2.4.21 및 2.6부터 `/proc/sys/kernel/core_pattern` 구성 파일을 사용하여 procfs를 통해 다른 이름을 지정할 수 있다. 지정된 이름은 실행 파일 이름, 프로세스 ID 또는 덤프 이유 등으로 대체되는 태그를 포함하는 템플릿일 수도 있다.^[17] 최신 유닉스 계열 시스템의 시스템 전체 덤프는 종종 `vmcore` 또는 `vmcore.incomplete`로 나타난다.

과거 운영체제에서는 프로세스의 주소 공간이 연속적이었기에 코어 덤프 파일은 단순히 주소 순서대로 바이트가 나열된 형태였다. 최근 운영체제에서는 프로세스의 주소 공간에 사용하지 않는 부분이 존재하며, 이를 표현하기 위해 파일 형식도 복잡해졌다. 또한, 덤프 수집 시점의 프로그램 상태 등 정보도 저장된다.

디버거에서는 코어 덤프를 생성한 실행 파일을 실행 시와 마찬가지로 로드하고, 여기에 코어 덤프가 출력한 메모리 이미지를 덮어씌움으로써 코어 덤프 생성 당시의 메모리를 재현한다. 예를 들어 ELF의 경우, 메모리 이미지는 프로그램 헤더의 LOAD 섹션, 부가 정보는 프로그램 헤더의 NOTE 섹션에 기술한다.

5. 2. 윈도우

마이크로소프트 윈도우와 같은 파일 확장자를 사용하는 시스템은 확장자 `.dmp`를 사용할 수 있다. 예를 들어, 코어 덤프는 `memory.dmp` 또는 `\Minidump\Mini051509-01.dmp`와 같이 명명될 수 있다.^[18]

마이크로소프트 윈도우는 두 가지 메모리 덤프 형식을 지원한다.

커널 모드 덤프에는 다섯 가지 유형이 있다:^[18]

전체 메모리 덤프: 대상 시스템의 전체 물리적 메모리를 포함한다.
커널 메모리 덤프: 충돌 시 커널이 사용 중인 모든 메모리를 포함한다.
소형 메모리 덤프: 중지 코드, 매개변수, 로드된 장치 드라이버 목록 등과 같은 다양한 정보를 포함한다.
자동 메모리 덤프 (Windows 8 이상): 커널 메모리 덤프와 동일하지만, 페이징 파일이 시스템 관리 대상이고 커널 메모리 덤프를 캡처하기에 너무 작은 경우, 페이징 파일을 4주 동안 RAM 크기 이상으로 자동으로 증가시킨 다음, 더 작은 크기로 줄인다.^[19]
활성 메모리 덤프 (Windows 10 이상): 커널 및 사용자 모드 애플리케이션에서 사용 중인 대부분의 메모리를 포함한다.

Windows 커널 모드 덤프를 분석하려면 Debugging Tools for Windows가 사용되며, WinDbg 및 DumpChk와 같은 도구를 포함하는 집합이다.^[20]^[21]^[22]

사용자 모드 메모리 덤프는, '''미니덤프'''라고도 하며,^[23] 단일 프로세스의 메모리 덤프이다. 여기에는 선택된 데이터 레코드가 포함된다. 전체 또는 부분(필터링된) 프로세스 메모리; 해당 스레드 목록과 해당 호출 스택 및 상태(예: 레지스터 또는 TEB); 커널 객체에 대한 핸들 정보; 로드되고 언로드된 라이브러리 목록을 포함한다. `MINIDUMP_TYPE` 열거형에서 사용 가능한 모든 옵션이 있다.^[24]

5. 3. OS/360 및 후속 제품

OS/360 및 후속 제품에서 작업은 형식화된 ABEND 덤프의 경우 `SYSABEND` 및 `SYSUDUMP`에 임의의 데이터 세트 이름(DSN)을 할당하고 SNAP 덤프의 경우 임의의 ddname을 할당하거나 해당 ddname을 SYSOUT으로 정의할 수 있다.^[8]

6. 한국의 관점 및 활용

한국의 IT 환경에서 코어 덤프는 시스템 안정성 유지 및 문제 해결에 중요한 역할을 한다.

6. 1. 서버 및 데이터센터 운영

코어 덤프는 운영 체제를 오프라인으로 디버깅할 수 있게 해주어 공유 컴퓨터에서 시스템을 즉시 다시 작동시킬 수 있도록 돕는다. 또한 코어 덤프는 사용자가 충돌을 나중에 또는 원격으로 분석하거나 다른 충돌과 비교하기 위해 저장할 수 있도록 해준다.^[1]

6. 2. 임베디드 시스템 개발

임베디드 시스템의 경우 컴퓨터 자체에서 디버깅을 지원하는 것이 비현실적일 수 있으므로, 다른 컴퓨터에서 덤프 분석을 수행할 수 있다.^[1] 한국의 발전된 임베디드 시스템 개발 환경에서, 코어 덤프는 하드웨어와 소프트웨어 간의 복잡한 상호 작용에서 발생하는 오류를 분석하는 데 필수적인 도구이다.

6. 3. 고가용성 시스템 구축

금융, 통신 등 고가용성이 요구되는 시스템에서 코어 덤프는 장애 발생 시 신속한 복구 및 시스템 안정성 유지에 기여한다. 공유 컴퓨터 환경에서 코어 덤프를 활용하면 운영 체제를 오프라인으로 디버깅할 수 있어 시스템을 빠르게 정상 작동 상태로 복구할 수 있다.^[1] 또한, 코어 덤프는 충돌 분석을 나중에 수행하거나 원격으로 분석하고, 다른 충돌과 비교하기 위해 저장할 수 있게 해준다.^[1]

7. 보안 문제 및 주의사항

코어 덤프는 생성 당시의 메모리 내용을 그대로 출력하므로, 보안상 민감한 정보를 포함할 수 있어 취급에 주의해야 한다. 신뢰할 수 없는 제3자에게 접근을 허용하지 않도록 관리해야 한다.^[4]

7. 1. 접근 제한

프로그램의 치명적인 오류는 많은 운영 체제에서 자동으로 코어 덤프를 발생시킨다. 코어 덤프는 생성 당시 메모리 내용을 그대로 출력하므로, 보안상 민감한 정보를 포함할 수 있다. 따라서 신뢰할 수 없는 제3자에게 접근을 허용하지 않는 등 취급에 주의해야 한다. 사용자 프로세스의 코어 덤프는 소유자 외에는 접근할 수 없도록 커널이 권한을 설정하는 경우가 많다.^[4] setuid 또는 setgid 비트 설정으로 실효 UID 또는 실효 GID를 변경한 프로세스는, 실 UID 또는 실 GID 사용자로부터 정보 유출을 방지하기 위해 코어 덤프를 생성하지 않는 것이 일반적이다.^[4] 커널 코어 덤프는 OS를 사용하던 모든 사용자의 정보가 포함되므로, 소유자는 보통 슈퍼 유저로 설정된다.^[4] 분석을 위해 코어 덤프를 외부로 반출하는 경우에는 반출 대상의 신뢰성을 확인하거나 코어 덤프를 암호화하는 등 보안 대책을 마련하는 것이 좋다.^[4]

7. 2. 커널 코어 덤프

커널 코어 덤프는 운영 체제(OS)를 사용하던 모든 사용자의 정보를 포함할 수 있기 때문에, 슈퍼 유저 권한으로 관리해야 한다.^[1] 분석을 위해 코어 덤프를 외부로 반출하는 경우에는 반출처가 신뢰할 수 있는지 확인하거나, 코어 덤프를 암호화하는 등의 보안 대책을 실시하는 것이 바람직하다.^[1]

7. 3. 외부 반출 시 보안

코어 덤프는 생성 당시의 메모리 내용을 그대로 출력하므로, 보안상 민감한 정보를 포함할 수 있어 취급에 주의해야 한다. 신뢰할 수 없는 제3자에게 접근을 허용하지 않도록 관리해야 한다. 사용자 프로세스의 코어 덤프는 보통 소유자 외에는 접근할 수 없도록 커널이 권한을 설정한다. setuid 또는 setgid 비트를 사용하여 실효 UID 또는 실효 GID를 변경한 프로세스에서는, 실 UID 또는 실 GID 사용자로부터의 엿보기를 방지하기 위해 코어 덤프를 생성하지 않는 것이 일반적이다. 커널 코어 덤프는 OS를 사용하던 모든 사용자의 정보가 포함될 수 있으므로, 소유자는 일반적으로 슈퍼 유저로 설정된다.

분석을 위해 코어 덤프를 외부로 반출하는 경우에는, 반출처가 코어 덤프를 안전하게 다룰 수 있는지 신뢰성을 확인해야 한다. 또한 코어 덤프를 암호화하는 등 보안 대책을 마련하는 것이 바람직하다.^[1]

8. 기타 활용

코어 덤프는 여러 상황에서 유용한 디버깅 보조 도구로 사용될 수 있다. 초기 독립형 또는 일괄 처리 시스템에서 코어 덤프는 사용자가 (매우 비싼) 컴퓨팅 시설을 독점하지 않고도 프로그램을 디버깅할 수 있게 해주었다. 또한 인쇄물은 전면 패널 스위치와 표시등을 사용하여 디버깅하는 것보다 더 편리했다.

시분할, 일괄 처리 또는 서버 시스템과 같은 공유 컴퓨터에서 코어 덤프를 사용하면 운영 체제를 오프라인으로 디버깅할 수 있으므로 시스템을 즉시 다시 작동시킬 수 있다.

코어 덤프를 사용하면 사용자가 충돌을 나중에 또는 원격으로 분석하거나 다른 충돌과 비교하기 위해 저장할 수 있다. 임베디드 시스템의 경우 컴퓨터 자체에서 디버깅을 지원하는 것이 비현실적일 수 있으므로 덤프 분석은 다른 컴퓨터에서 수행될 수 있다. 초기 버전의 유닉스와 같은 일부 운영 체제는 실행 중인 프로세스에 디버거를 연결하는 것을 지원하지 않았으므로, 프로세스의 메모리 내용을 디버거에서 실행하려면 코어 덤프가 필요했다.

코어 덤프는 동적 메모리 할당 중에 해제된 데이터를 캡처하는 데 사용할 수 있으므로, 더 이상 실행되지 않는 프로그램에서 정보를 검색하는 데 사용할 수 있다. 대화형 디버거가 없는 경우 꼼꼼한 프로그래머가 코어 덤프를 사용하여 직접 검사를 통해 오류를 확인할 수 있다.

스냅 덤프는 응용 프로그램이 빠르고 지저분한 디버깅 출력을 기록하는 편리한 방법이 되기도 한다.

8. 1. 고가용성 시스템

시스템은 프로세서 간 코어 덤프 파일을 전송하여 가용성을 높이기도 한다.^[30] 이는 고가용성 시스템에서 활용되는 방법 중 하나이다.

8. 2. 시작 비용 절감

코어 덤프는 GNU Emacs나 Perl과 같이 시작 비용이 매우 높은 소프트웨어에서 시작 시간을 단축하는 데 사용될 수 있다. 이 기법은 특정 시점에서 코어 덤프를 저장해 두고 나중에 해당 상태로 되돌리는 방식으로 작동한다.^[1] 또한 미리 컴파일된 헤더 기술에서는 컴파일러가 헤더 파일을 처리하는 시점에서 코어 덤프를 생성하여 헤더 파일 처리 시간을 절약하기도 한다.^[1]

8. 3. 컴파일 시간 단축

미리 컴파일된 헤더 기술에서 컴파일러가 헤더 파일을 처리하는 시점에 코어 덤프를 생성하여, 헤더 파일 처리 시간을 절약하는 등의 방법으로 컴파일 시간을 단축할 수 있다.

9. 속어

일본에서는 프로그램이 이상 종료되어 코어 덤프를 출력하는 것을 속어로 "코어를 '''토하다'''"라고 표현한다. 이는 구토를 의미하는 "(리얼) 코어 덤프한다"라는 자르곤으로도 사용된다.

참조

_[1] 웹사이트 AIX 7.1 information http://pic.dhe.ibm.c[...]
_[2] 매뉴얼 Process core file Solaris
_[3] 웹사이트 What is a Database Dump? - Definition from Techopedia http://www.techopedi[...] 2015-06-29
_[4] 웹사이트 How to configure a computer to capture a complete memory dump https://www.sophos.c[...] 2015-06-29
_[5] 사전 core Oxford English Dictionary
_[6] 서적 UNIX: a history and a memoir
_[7] 웹사이트 storage dump definition http://encyclopedia2[...] 2013-04-03
_[8] 서적 z/OS Diagnostic Data Collection and Analysis http://www.redbooks.[...] IBM Corporation 2021-01-29
_[9] 서적 z/VM and Linux Operations for z/OS System Programmers http://www.redbooks.[...] 2022-01-25
_[10] 서적 Essential Linux device drivers https://books.google[...] Prentice Hall 2010-07-15
_[11] 서적 Fedora 13 Security Guide https://books.google[...] Fultus Corporation 2010-09-29
_[12] 매뉴얼 IBM 7090/7094 IBSYS Operating System - Version 13 - System Monitor (IBSYS) http://bitsavers.org[...] IBM 2024-05-10
_[13] 매뉴얼 z/OS 2.5 MVS System Commands https://www.ibm.com/[...] 2022-04-06
_[14] 매뉴얼 OS/VS2 MVS Interactive Problem Control System (IPCS) System Information - SUID 5752-857 http://bitsavers.org[...] IBM 2023-06-29
_[15] 매뉴얼 OS/VS2 MVS Interactive Problem Control System User's Guide and Reference - SUID 5752-857 http://bitsavers.org[...] IBM 2023-06-29
_[16] 매뉴얼 z/OS 2.5 - MVS Interactive Problem Control System (IPCS) Commands https://www.ibm.com/[...] IBM 2022-04-06
_[17] 웹사이트 core(5) – Linux manual page http://man7.org/linu[...] 2016-04-17
_[18] 웹사이트 Varieties of Kernel-Mode Dump Files https://docs.microso[...] Microsoft 2018-02-22
_[19] 웹사이트 Automatic Memory Dump https://docs.microso[...] Microsoft 2018-03-16
_[20] 웹사이트 Getting Started with WinDbg (Kernel-Mode) http://msdn.microsof[...] 2014-09-30
_[21] 웹사이트 Get started with Windows debugging https://learn.micros[...] 2024-12-14
_[22] 웹사이트 Tools included in Debugging Tools for Windows https://learn.micros[...] 2024-12-14
_[23] 웹사이트 Minidump Files http://msdn.microsof[...] 2014-09-30
_[24] 웹사이트 MINIDUMP_TYPE enumeration http://msdn.microsof[...] 2014-09-30
_[25] 웹인용 AIX 7.1 information http://pic.dhe.ibm.c[...]
_[26] 매뉴얼 Process core file Solaris
_[27] 사전 core Oxford English Dictionary
_[28] 웹인용 storage dump definition http://encyclopedia2[...]
_[29] 서적 Essential Linux device drivers http://books.google.[...] Prentice Hall 2010-07-15
_[30] 서적 Fedora 13 Security Guide http://books.google.[...] Fultus Corporation 2010-09-29

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com