3.4. 충돌한 애플리케이션 디버깅

절차

1. 코어 덤프를 활성화하려면 /etc/systemd/system.conf 파일에 다음 행이 포함되어 있는지 확인하십시오.

   DumpCore=yes
   DefaultLimitCORE=infinity

   이러한 설정이 이전에 있는지 및 이전 값이 무엇인지에 대한 주석을 추가할 수도 있습니다. 필요한 경우 나중에 이러한 변경 사항을 되돌릴 수 있습니다. 주석은 # 문자로 시작하는 행입니다.

   파일을 변경하려면 관리자 수준 액세스 권한이 필요합니다.

2. 새 구성을 적용합니다.

   # systemctl daemon-reexec

3. 코어 덤프 크기의 제한을 제거합니다.

   # ulimit -c unlimited

   이 변경을 취소하려면 무제한 이 아니라 값이 0 인 명령을 실행합니다.

4. 시스템 정보 수집을 위한 sosreport 유틸리티를 제공하는 sos 패키지를 설치합니다.

   # yum install sos

5. 애플리케이션이 충돌하면 systemd-coredump 에 의해 코어 덤프가 생성되고 처리됩니다.

6. 시스템에 대한 추가 정보를 제공하는 SOS 보고서를 생성합니다.

   # sosreport

   이렇게 하면 구성 파일 복사본과 같은 시스템에 대한 정보가 포함된 .tar 아카이브가 생성됩니다.

7. 코어 덤프를 찾아서 내보냅니다.

   $ coredumpctl list executable-name
   $ coredumpctl dump executable-name > /path/to/file-for-export

   애플리케이션이 여러 번 충돌하면 첫 번째 명령의 출력에 더 캡처된 코어 덤프가 나열됩니다. 이 경우 두 번째 명령의 구문을 구문을 사용하여 다른 정보를 사용하여 보다 정확한 쿼리를 만듭니다. 자세한 내용은 coredumpctl(1) 매뉴얼 페이지를 참조하십시오.

8. 코어 덤프와 SOS 보고서를 디버깅이 수행되는 컴퓨터로 전송합니다. 알려진 경우 실행 파일을 전송합니다.

   중요

   실행 파일을 알 수 없는 경우 코어 파일의 후속 분석이 해당 파일을 식별합니다.

9. 선택 사항: 코어 덤프 및 SOS 보고서를 전송 후 제거하여 디스크 공간을 확보합니다.

절차

1. 충돌이 발생한 실행 파일을 식별하려면 코어 덤프 파일을 사용하여 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

   출력에는 공백으로 구분된 행의 각 모듈에 대한 세부 정보가 포함되어 있습니다. 정보는 다음 순서로 나열됩니다.

   1. 모듈이 매핑된 메모리 주소
   2. 모듈의 build-id 및 검색된 메모리의 위치
   3. 모듈의 실행 파일 이름, 알 수 없는 경우 또는 로 표시됨 또는 모듈이 파일에서 로드되지 않은 경우
   4. 사용 가능한 경우 파일 이름으로 표시되는 디버깅 정보의 소스입니다 . 실행 파일 자체에 포함된 경우 또는 전혀 표시되지 않는 경우 입니다.
   5. 기본 모듈의 공유 라이브러리 이름(soname) 또는 [exe]

   이 예에서 중요한 세부 사항은 텍스트 [exe] 를 포함하는 행의 파일 이름 /usr/bin/sleep 및 build-id 2818b2009547f780a56394cded443e564973e 입니다. 이 정보를 사용하여 코어 덤프를 분석하는 데 필요한 실행 파일을 식별할 수 있습니다.

2. 충돌한 실행 파일을 가져옵니다.

   • 가능한 경우 충돌이 발생한 시스템에서 복사합니다. 코어 파일에서 추출한 파일 이름을 사용합니다.

   • 시스템에서 동일한 실행 파일을 사용할 수도 있습니다. Red Hat Enterprise Linux를 기반으로 빌드된 각 실행 파일에는 고유한 build-id 값이 포함된 참고 사항이 포함되어 있습니다. 로컬에서 사용 가능한 관련 실행 파일의 build-id를 확인합니다.

     $ eu-readelf -n executable_file

     이 정보를 사용하여 원격 시스템의 실행 파일과 로컬 사본을 일치시킵니다. 코어 덤프에 나열된 로컬 파일 및 build-id의 build-id가 일치해야 합니다.

   • 마지막으로, 애플리케이션이 RPM 패키지에서 설치된 경우 패키지에서 실행 파일을 가져올 수 있습니다. sosreport 출력을 사용하여 필요한 패키지의 정확한 버전을 찾습니다.
3. 실행 파일에서 사용하는 공유 라이브러리를 가져옵니다. 실행 파일에 대해 와 동일한 단계를 사용합니다.
4. 애플리케이션이 패키지로 배포되는 경우 GDB에서 실행 파일을 로드하여 누락된 debuginfo 패키지에 대한 힌트를 표시합니다. 자세한 내용은 3.1.4절. “GDB를 사용하여 애플리케이션 또는 라이브러리의 debuginfo 패키지 가져오기” 의 내용을 참조하십시오.

5. 핵심 파일을 자세히 검사하려면 GDB를 사용하여 실행 파일 및 코어 덤프 파일을 로드합니다.

   $ gdb -e executable_file -c core_file

   누락된 파일 및 디버깅 정보에 대한 추가 메시지는 디버깅 세션에 누락된 항목을 식별하는 데 도움이 됩니다. 필요한 경우 이전 단계로 돌아갑니다.

   애플리케이션의 디버깅 정보를 패키지 대신 파일로 사용할 수 있는 경우 기호-file 명령을 사용하여 GDB에서 이 파일을 로드합니다.

   (gdb) symbol-file program.debug

   program.debug 를 실제 파일 이름으로 교체합니다.

   참고

   코어 덤프에 포함된 모든 실행 파일에 대한 디버깅 정보를 설치할 필요가 없을 수도 있습니다. 이러한 실행 가능한 파일은 애플리케이션 코드에서 사용하는 라이브러리입니다. 이러한 라이브러리는 분석 중인 문제에 직접 기여하지 않을 수 있으며, 디버깅 정보를 포함할 필요가 없습니다.

6. GDB 명령을 사용하여 충돌 시 애플리케이션 상태를 검사합니다. GDB를 사용한 애플리케이션 내부 상태 검사 참조.

   참고

   코어 파일을 분석할 때 GDB는 실행 중인 프로세스에 연결되지 않습니다. 실행을 제어하기 위한 명령에는 아무런 영향이 없습니다.

절차

1. 실행 파일 이름의 알려진 부분에 따라 중단 프로세스의 PID를 찾습니다.

   $ pgrep -a executable-name-fragment

   이 명령은 양식으로 행을 출력합니다.

   PID command-line

   명령줄 값을 사용하여 PID 가 의도한 프로세스에 속하는지 확인합니다.

   예를 들면 다음과 같습니다.

   $ pgrep -a bc
   5459 bc

2. 프로세스에 중단 신호를 보냅니다.

   # kill -ABRT PID

3. core dumpctl에서 코어 를 캡처했는지 확인합니다.

   $ coredumpctl list PID

   예를 들면 다음과 같습니다.

   $ coredumpctl list 5459
   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. 필요에 따라 핵심 파일을 추가로 검사하거나 사용합니다.

   코어 덤프를 PID 및 기타 값으로 지정할 수 있습니다. 자세한 내용은 coredumpctl(1) 매뉴얼 페이지를 참조하십시오.

   • 핵심 파일의 세부 정보를 보려면 다음을 수행합니다.

     $ coredumpctl info PID

   • GDB 디버거에서 코어 파일을 로드하려면 다음을 수행합니다.

     $ coredumpctl debug PID

     디버깅 정보의 가용성에 따라 GDB에서 실행할 명령을 제안합니다. 예를 들면 다음과 같습니다.

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     이 프로세스에 대한 자세한 내용은 3.1.4절. “GDB를 사용하여 애플리케이션 또는 라이브러리의 debuginfo 패키지 가져오기” 을 참조하십시오.

   • 다른 곳에서 추가 처리를 위해 코어 파일을 내보내려면 다음을 수행합니다.

     $ coredumpctl dump PID > /path/to/file_for_export

     /path/to/file_for_export 를 코어 덤프를 배치하려는 파일로 바꿉니다.

절차

1. 프로세스 ID(pid)를 확인합니다. ps,pgrep 및 top 과 같은 툴 사용 :

   $ ps -C some-program

2. 이 프로세스의 메모리를 덤프합니다.

   $ gcore -o filename pid

   그러면 파일 파일 이름이 생성되고 여기에 프로세스 메모리를 덤프합니다. 메모리가 덤프되는 동안 프로세스 실행이 중지됩니다.

3. 코어 덤프가 완료되면 프로세스가 정상적인 실행을 재개합니다.

4. 시스템에 대한 추가 정보를 제공하는 SOS 보고서를 생성합니다.

   # sosreport

   이렇게 하면 구성 파일 복사본과 같은 시스템에 대한 정보가 포함된 tar 아카이브가 생성됩니다.

5. 프로그램의 실행 파일, 코어 덤프 및 SOS 보고서를 디버깅이 수행되는 컴퓨터로 전송합니다.
6. 선택 사항: 코어 덤프 및 SOS 보고서를 전송 후 제거하여 디스크 공간을 확보합니다.

절차

1. /proc/PID/coredump_filter 파일의 설정을 무시하도록 GDB를 설정합니다.

   (gdb) set use-coredump-filter off

2. 메모리 페이지 플래그 VM_DONTDUMP 를 무시하도록 GDB를 설정합니다.

   (gdb) set dump-excluded-mappings on

3. 메모리를 덤프합니다.

   (gdb) gcore core-file

   core-file 을 메모리를 덤프하려는 파일의 이름으로 바꿉니다.