3.4. Crashed 애플리케이션 디버깅

프로세스

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

   DumpCore=yes
   DefaultLimitCORE=infinity

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

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

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

   # systemctl daemon-reexec

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

   # ulimit -c unlimited

   이 변경 사항을 되돌리려면 무제한 대신 값 0 을 사용하여 명령을 실행합니다.

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

   # dnf install sos

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

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

   # sosreport

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

7. 코어 덤프를 찾습니다.

   $ coredumpctl list executable-name

8. 코어 덤프를 내보냅니다.

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

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

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

   중요

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

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

프로세스

1. 크래시가 발생한 실행 파일을 확인하려면 core dump 파일을 사용하여 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 2818b2009547f780a5639c904cded443e564973e 564973e입니다. 이 정보를 사용하면 코어 덤프 분석에 필요한 실행 파일을 확인할 수 있습니다.

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

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

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

     $ eu-readelf -n executable_file

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

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

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

   $ gdb -e executable_file -c core_file

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

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

   (gdb) symbol-file program.debug

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

   참고

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

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

   참고

   코어 파일을 분석할 때 GDB는 실행 중인 프로세스에 연결되어 있지 않습니다. 실행을 제어하는 명령은 영향을 미치지 않습니다.

7. 종료 시 애플리케이션 스택만 보려면 eu-stack 유틸리티를 사용하여 코어 파일을 엽니다.

   $ *eu-stack --core __core-file__*

   그러면 애플리케이션 스택 목록이 표시됩니다.

프로세스

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

   $ pgrep -a executable-name-fragment

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

   PID command-line

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

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

   $ pgrep -a bc

   5459 bc

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

   # kill -ABRT PID

3. coredumpctl 에 의해 코어가 캡처되었는지 확인합니다.

   $ 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-23.el10.x86_64

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

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

     $ coredumpctl dump PID > /path/to/file_for_export

   • /path/to/file_for_export 를 코어 덤프를 배치할 파일로 바꿉니다.

     $ coredumpctl dump PID > /path/to/file_for_export

프로세스

1. 프로세스 ID(pid)를 확인합니다. ps,pgrep 와 같은 도구를 사용하십시오.

   $ 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 을 메모리를 덤프하려는 파일 이름으로 교체합니다.