나는 클라이언트의 Solaris SPARC 시스템에서 코어 파일 생성 시 이상한 동작을 식별하기 위해 한동안 작업해 왔습니다. 현재 Solaris 버전은 11.4-11.4.44.0.1.113.4입니다. 애플리케이션은 GCC 11.2 및 -g를 사용하여 구축되었습니다. 애플리케이션과 코어 파일은 GDB 10.2 및 pstack을 사용하여 디버깅됩니다.
나는 고객에게 이 문제를 분석하고 진단하는 데 도움이 되는 특별한 도구를 제공합니다. 애플리케이션이 하는 일은 분할 오류로 인해 코어 파일을 생성하는 것뿐입니다.
문제: 클라이언트 시스템에서 생성된 코어 파일은 GDB를 사용하여 스택, 변수 또는 메모리 정보를 표시하지 않습니다. 그러나 내 개발 시스템에서 코어 파일을 생성하기 위해 정확히 동일한 실행 파일을 사용하면 디버깅할 수 있는 코어 파일이 생성됩니다.
처음에는 이것이 Solaris 11.4 패치 비호환성과 관련이 있을 수 있다고 생각했습니다. 클라이언트에서 얻은 코어 파일 세트에 대해 11.4.39부터 11.4.47까지 모든 Solaris 패치 레벨을 시도했지만 큰 차이는 없었습니다.
예를 들어 개발 시스템에서 코어 파일은 GDB에서 생성됩니다.
. . .
core_dump_tool.exe에서 기호를 읽는 중...
[신규 LWP 1]
[libthread_db를 사용하여 스레드 디버깅 활성화]
[새 스레드 1(LWP 1)]
코어는 "./core_dump_tool.exe"에 의해 생성됩니다.
프로그램이 SIGSEGV 신호(세그먼트 오류)로 종료되었습니다.
/usr/lib/libc.so.1의 _malloc_unlocked()에 있는 #0 0xfe3cdc80
[현재 쓰레드는 1(LWP 1)]
(gdb) 어디에
/usr/lib/libc.so.1의 _malloc_unlocked()에 있는 #0 0xfe3cdc80
#1 /usr/lib/libc.so.1의 do_malloc()에 있는 0xfe3cd9d4
#2 core_dump_tool.c:82의 버퍼 오버플로(iDataLength=100, cpData=0xffbff140 12 34567890123456789")의 0x00011a40
#3 core_dump_tool.c:232의 main()에 있는 0x00011f80
역추적 중지됨: 이 프레임 내의 이전 프레임(스택 손상?)
(gdb) 종료
. . .
정확히 동일한 애플리케이션이 클라이언트 시스템에서 실행되면 결과 코어 파일이 GDB에 이 파일을 생성합니다.
. . .
core_dump_tool.exe에서 기호를 읽는 중...
[신규 LWP 1]
[libthread_db를 사용하여 스레드 디버깅 활성화]
[새 스레드 1(LWP 1)]
코어는 "core_dump_tool.exe"에 의해 생성됩니다.
프로그램이 SIGSEGV 신호(세그먼트 오류)로 종료되었습니다.
/usr/lib/libc.so.1의 _malloc_unlocked()에 있는 #0 0xfeb6daf0
(gdb)BT
/usr/lib/libc.so.1의 _malloc_unlocked()에 있는 #0 0xfeb6daf0
#1 0x00022514??()
역추적 중지됨: 이전 프레임이 이 프레임과 동일합니다(스택 손상?)
(gdb) 종료
. . .
고객의 시스템과 시스템에서 생성된 핵심 파일에 대한 질문입니다.
- 이 문제는 2021년 12월에 처음 나타났습니다. 2021년 9월부터 2021년 12월 초 사이쯤에 코어 파일 문제를 좁힐 수 있었습니다.
- 고객은 이 기간 동안 생산 기계에 어떤 변화가 있었는지 전혀 모릅니다. 기록을 찾을 수 없었고 관리자는 떠났습니다.
- 클라이언트로부터 영향을 받는 시스템에 대한 coreadm 및 dumpadm 구성을 요청했지만 아직 정보를 받지 못했습니다.
고객이 핵심 파일을 생성하는 시스템에 미칠 수 있는 영향에 대한 아이디어나 생각이 있는 분이 계시다면 감사하겠습니다.
답변1
귀하의 클라이언트는 문제의 시스템에서 코어 파일 크기가 제한되어 있을 수 있습니다.
Solaris는 스택 정보를 코어 파일에 기록합니다.마지막, 따라서 코어 파일 크기에 리소스 제약이 있는 경우 스택 정보가 코어 파일에 기록되지 않습니다. 그리고 코어 파일은 디버깅에 사실상 쓸모가 없습니다.
Solaris에는 두 가지 유용한 코어 파일 크기 제한 설정이 있습니다. 0코어 파일이 생성되지 않도록 방지하여 unlimited결과 코어 파일이 실제로효과가있다.
또한 설정에 대한 참고 사항 - 코어 파일 이름에서 프로세스 이름, PID, 시간 및 유사한 데이터를 캡처하거나 더 많은 것을 보존하는 등의 작업을 수행하기 위해 coreadm프로세스의 현재 작업 디렉터리에서 기본 코어 파일 모드를 변경하는 경우 core정보 마지막 코어 파일보다 core또는 전역 코어 파일 설정을 사용하여 모든 코어 파일을 공통 위치에 캡처합니다.이제 핵심 파일이 저장 공간을 가득 채우기 전에 사전에 관리해야 합니다..
중요한 시스템의 프로세스가 빠른 장애 조치 상태가 되고 매번 새 코어 파일이 생성되면 어떻게 됩니까? 디스크가 가득 차고 시스템이 충돌하는 것은 coreadm모든 코어 파일을 보존하는 코어 파일 이름 패턴을 설정했기 때문입니다.
이런.
고객에게 모든 코어 파일을 보존하기 위해 코어 파일 이름 패턴을 설정하도록 지시하거나 이를 수행하도록 자체 시스템을 구성하도록 지시하지 마십시오. 그렇게 하는 경우 해당 시스템에서 코어 파일을 적극적으로 관리해야 한다는 점을 알려주십시오.
"코어 파일을 사전에 관리한다"는 것은 "매일 cron 작업을 실행한다"는 의미는 아닙니다. 무엇을 하든 분당 500개의 코어 파일을 생성하는 폭주 프로세스를 처리할 수 있어야 합니다.
또는 최소한 시스템 저장소의 나머지 부분을 채울 수 없는 전용 파일 시스템에 작성된 전역 코어 파일을 사용하도록 지시하여 해당 전용 코어 파일 모음 파일 시스템이 가득 차도 나머지 부분에 손상이 가해지지 않도록 하십시오. 시스템이 체계적이다.