자동 버그 보고 도구(ABRT) 시스템이 문제를 감지합니다.
$ sudo su -
마지막 로그인: 목 3월 23 15:08:29 KST 2023 일시 pts/2
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1679551709자동 버그 보고 도구(ABRT)가 시스템에서 하나 이상의 문제를 감지했습니다.
자세한 내용은 터미널에서 다음 명령을 실행할 수 있습니다.
abrt-cli list --since 1679551709이 명령은 지정된 타임스탬프(1679551709) 이후 ABRT가 감지한 모든 문제를 나열합니다.
여기에서 각 문제를 자세히 검토하고 문제를 해결하기 위한 적절한 조치를 취할 수 있습니다.
$ abrt-cli list --since 1679551709
id e06f6433b023c113e6e4b04fead13ab32204c48c
reason: siege killed by SIGSEGV
time: 2023년 03월 23일 (목) 오후 04시 45분 41초
cmdline: siege -c 650 -r 1 https://sangchul.kr
package: siege-4.1.1-1.el7
uid: 0 (root)
count: 1
Directory: /var/spool/abrt/ccpp-2023-03-23-16:45:41-29938
자동보고 기능은 비활성화되어 있습니다.
root 권한을 가진 사용자로
'abrt-auto-reporting enabled'를 실행하여 이를 활성화합니다코어 덤프 파일을 확인하는 방법
1. coredump 파일이 있는 경로로 이동합니다.
여기서는 /var/spool/abrt/ccpp-2023-03-23-16:45:41-29938이 존재한다고 가정합니다.
cd /var/spool/abrt/ccpp-2023-03-23-16:45:41-29938
2. 이 경로에서 ls 명령을 사용하여 coredump 파일을 확인합니다.
코어 덤프 파일의 이름은 일반적으로 “코어 덤프” 또는 “코어”입니다.
ls -l coredump
3. coredump 파일이 있으면 gdb(GNU Debugger)로 파일을 분석합니다.
gdb -c coredump$ gdb -c coredump
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(New LWP 30590)
(New LWP 30400)
(New LWP 29938)
Missing separate debuginfo for the main executable file
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/d9/5dcb75d353394ff06e3ee838d1b03592240864
Core was generated by `siege -c 650 -r 1 https://sangchul.kr'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f1dd40feb81 in ?? ()
4. gdb를 실행할 때 “bt” 명령을 사용하여 백트레이스를 확인할 수 있습니다.
역추적은 프로그램이 종료되기 전에 수행한 함수 호출 스택을 보여주고 문제를 식별하는 데 도움이 될 수 있습니다.
bt(gdb) bt
#0 0x00007f1dd40feb81 in ?? ()
#1 0x0000000000000008 in ?? ()
#2 0x000000000040c4a9 in ?? ()
#3 0x0000000000e71170 in ?? ()
#4 0x0000000000000000 in ?? ()위의 과정을 따라 ABRT에서 생성된 coredump 파일을 확인하고 문제를 분석할 수 있습니다.
5. 다른 명령도 gdb에서 사용할 수 있습니다.
예를 들어 “info registers” 명령으로 레지스터 정보를 확인할 수 있습니다.
info registers(gdb) info registers
rax 0xed1e00 15539712
rbx 0x8 8
rcx 0x1c 28
rdx 0x1c 28
rsi 0x1 1
rdi 0x7f1dd1e10700 139766051964672
rbp 0xe71170 0xe71170
rsp 0x7f1c8cb85d40 0x7f1c8cb85d40
r8 0x7f1dd35fe9f0 139766077057520
r9 0x1 1
r10 0x7f1c8cb85910 139760596703504
r11 0x7f1dd40feb80 139766088592256
r12 0x1450 5200
r13 0x801000 8392704
r14 0x0 0
r15 0x7f1c8cb86700 139760596707072
rip 0x7f1dd40feb81 0x7f1dd40feb81
eflags 0x10206 ( PF IF RF )
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
6. 문제를 해결하려면 무엇이 잘못되었는지 찾기 위해 코어 덤프 파일의 정보를 분석해야 합니다.
이를 위해서는 프로그램 소스코드와 디버그 정보를 함께 분석하는 것을 권장한다.
7. ABRT가 코어 덤프 파일을 수집하지 않은 경우 코어 덤프 파일을 직접 수집해야 합니다.
이렇게 하려면 “ulimit -c unlimited” 명령을 사용하여 코어 덤프 파일 생성을 활성화해야 합니다.
나중에 프로그램이 충돌하면 gdb로 분석할 수 있는 코어 덤프 파일이 생성됩니다.
위의 과정을 참고하여 coredump 파일을 분석하고 문제를 해결할 수 있습니다.