21.3. 코어 덤프를 사용하여 애플리케이션 Crash 상태 검사
사전 요구 사항
- 코어 덤프 파일 및 SOS 보고서
- GDB 및 elfutils가 시스템에 설치되어 있습니다.
절차
충돌이 발생한 실행 파일을 식별하려면 코어 덤프 파일을 사용하여
eu-unstrip
명령을 실행합니다.$ eu-unstrip -n --core=./core.9814 0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe] 0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1 0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6 0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2
출력에는 공백으로 구분된 한 줄의 각 모듈에 대한 세부 정보가 포함되어 있습니다. 정보는 다음 순서로 나열됩니다.
- 모듈이 매핑된 메모리 주소
- 모듈의 build-id 및 검색된 메모리의 위치
-
모듈의 실행 파일 이름, 알 수 없는
경우
또는 로 표시됨 또는 모듈이파일에서
로드되지 않은 경우 -
사용 가능한 경우 파일 이름으로 표시되는 디버깅 정보의 소스입니다
.
실행 파일 자체에 포함된 경우 또는 전혀 표시되지 않는경우
입니다. -
기본 모듈의 공유 라이브러리 이름(soname), 또는
[exe]
이 예에서 중요한 세부 사항은 텍스트
[exe]
를 포함하는 행의 파일 이름/usr/bin/sleep
및 build-id2818b2009547f780a56394cded443e564973e
입니다. 이 정보를 사용하여 코어 덤프를 분석하는 데 필요한 실행 파일을 식별할 수 있습니다.충돌한 실행 파일을 가져옵니다.
- 가능한 경우 충돌이 발생한 시스템에서 복사합니다. 코어 파일에서 추출한 파일 이름을 사용합니다.
또는 시스템에서 동일한 실행 파일을 사용합니다. Red Hat Enterprise Linux를 기반으로 빌드된 각 실행 파일에는 고유한 build-id 값이 포함된 참고 사항이 포함되어 있습니다. 로컬에서 사용 가능한 관련 실행 파일의 build-id를 확인합니다.
$ eu-readelf -n executable_file
이 정보를 사용하여 원격 시스템의 실행 파일과 로컬 사본을 일치시킵니다. 코어 덤프에 나열된 로컬 파일 및 build-id의 build-id가 일치해야 합니다.
-
마지막으로, 애플리케이션이 RPM 패키지에서 설치된 경우 패키지에서 실행 파일을 가져올 수 있습니다.
sosreport
출력을 사용하여 필요한 패키지의 정확한 버전을 찾습니다.
- 실행 파일에서 사용하는 공유 라이브러리를 가져옵니다. 실행 파일에 대해 와 동일한 단계를 사용합니다.
- 애플리케이션이 패키지로 배포되는 경우 GDB에서 실행 파일을 로드하여 누락된 debuginfo 패키지의 힌트를 표시합니다. 자세한 내용은 20.1.4절. “GDB를 사용하여 애플리케이션 또는 라이브러리용 debuginfo 패키지 가져오기” 의 내용을 참조하십시오.
핵심 파일을 자세히 검사하려면 GDB를 사용하여 실행 파일 및 코어 덤프 파일을 로드합니다.
$ gdb -e executable_file -c core_file
누락된 파일 및 디버깅 정보에 대한 추가 메시지는 디버깅 세션에 누락된 항목을 식별하는 데 도움이 됩니다. 필요한 경우 이전 단계로 돌아갑니다.
패키지 대신 디버깅 정보를 파일로 사용할 수 있는 경우 GDB에서
symbol-file
명령을 사용하여 이 파일을 로드합니다.(gdb) symbol-file program.debug
program.debug 를 실제 파일 이름으로 교체합니다.
참고코어 덤프에 포함된 모든 실행 파일에 대한 디버깅 정보를 설치할 필요가 없을 수도 있습니다. 이러한 실행 가능한 파일은 애플리케이션 코드에서 사용하는 라이브러리입니다. 이러한 라이브러리는 분석 중인 문제에 직접 기여하지 않을 수 있으며, 디버깅 정보를 포함할 필요가 없습니다.
GDB 명령을 사용하여 충돌 시 애플리케이션 상태를 검사합니다. 20.2절. “GDB를 사용하여 애플리케이션의 내부 상태 검사”을 참조하십시오.
참고코어 파일을 분석할 때 GDB는 실행 중인 프로세스에 연결되지 않습니다. 실행을 제어하기 위한 명령에는 아무런 영향이 없습니다.
추가 리소스
- GDB를 사용한 디버깅 - 2.1.1 파일 확인
- GDB - 18.1 파일을 지정하는 명령을 사용하여 디버깅
- GDB를 사용한 디버깅 - 18.3 별도의 파일에서 디버깅 정보 https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html