.png)
시나리오(우분투 16.04):
나는 C 프로그램을 컴파일하고 실행합니다( 를 사용하여 -g전통적인 을 얻습니다 Segmentation Fault (core dumped). 그리고 (물론) 신화적인 "핵심" 파일을 찾을 수 없습니다. 일부 조사에 따르면 다음과 같은 효과 /proc/sys/kernel/core_pattern를 위해 명령을 사용하여 수정하라고 합니다. echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern이, 나는 얻는 것을 멈추고 (core dumped)일반 Segmentation Fault. 내가 있어야 할 곳으로 이동하기 위해 자동 완성 기능을 사용하세요.gdb ./program_object_file.out core.pidgdb ./a.out(gdb) core core.pidtab
질문:
코어 덤프에 접근할 수 있는 일반화된 방법이 있습니까? 나는 내가 만지는 모든 기계에는마이클 베이의 트랜스포머- 내가 소유한 어떤 장치도 기본적으로 정상적으로 작동할 것으로 예상할 수 없도록 하드웨어와 소프트웨어를 재구성하는 것과 같은 능력입니다. 내 컴퓨터와 다른 사람의 컴퓨터에서 코어 덤프를 찾기 위해 따를 수 있는 간단한 알고리즘/레시피가 있습니까? 나는 항상 나 자신을 위해 일하기 위해 적지 않은 작업을 한 후에 이런 일에 대해 친구를 가르치는 것을 발견했습니다. 명령이나 무언가를 실행하여 실행 파일이 실행된 디렉터리에 코어 파일을 덤프할 수 있으면 좋을 것입니다. ... 대부분의("일부") Linux/Unix 시스템에서 작동하는 이 작업을 수행할 수 있는 방법이 있습니까?
답변1
그만큼core(5)맨페이지에는 이름 지정 등을 포함하여 코어 덤프에 영향을 미치는 매개 변수가 자세히 설명되어 있습니다.
귀하가 언급한 질문에 대답하기 위해 코어 덤프를 찾는 일반화 가능한 방법은 없습니다. 기본적으로 코어는프로세스의 현재 작업 디렉터리, 프로세스가 거기에 쓸 수 있는 경우, 포함하는 파일 시스템에 충분한 공간이 있는 경우, 기존 코어 덤프가 없는 경우(일부 상황에서), 파일 크기와 코어 파일 크기가 제한되는 경우(다음에 의해 설정됨) ulimit또는 유사한 메커니즘)을 허용합니다. 그러나 /proc/sys/kernel/core_pattern코어 덤프를 처리하는 다양한 방법을 제공하므로 해당 방법도 살펴보고 무슨 일이 일어나고 있는지 파악해야 합니다.
귀하의 경우 처음에 코어를 찾을 수 없는 이유는 모르겠지만 리디렉션을 설정한 후 코어 가져오기를 중단한 이유는 알고 있습니다. 에서 파이프를 사용할 때 core_pattern처리 프로그램~ 해야 하다절대 경로 이름을 사용하여 지정해야 합니다. tee그 자체로는 사용되지 않습니다. 를 지정해야 합니다 /usr/bin/tee. 코어 덤프를 처리하기 위해 실행되는 프로그램은 root.
데비안 파생물에 설치합니다corekeeper, 쉽게 사용할 수 있는 방식으로 아래의 사용자별 디렉터리에 코어 덤프를 기록합니다 /var/crash.
답변2
(질문의 OP에서 답변으로 답변 이동)
실제로 무엇이 잘못되었는지 식별하는 데 도움이 되었기 때문에 아래 답변을 정답으로 표시했으며 나중에 다시 돌아와 이 문제를 좀 더 구체화하고 싶지만 현재 솔루션(대부분의 경우 효과가 있을 것으로 생각됩니다) Linux 머신)은 다음 명령을 사용하는 것입니다.
cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern
.core_pattern.bak이렇게 하면 이전 코어 덤핑 방법을 홈 폴더의 숨겨진 파일( )로 백업하고 다음을 사용하여 복원할 수 있습니다.
sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern
두 번째 명령은 코어 덤프 core가 dump. 분명히 이 형식을 수정하여 원하는 대로 패턴을 얻을 수 있습니다. 그러나 내가 알 수 있는 한, 이것은 한 번에 하나의 코어 덤프만 저장한다는 점에 유의해야 합니다(각각의 새로운 덤프는 오래된 덤프를 망칠 것입니다). 왜냐하면 제가 개인적으로 코어 덤프를 확인한다면 그것은 방금 실행된 프로그램이고 오래된 덤프를 보관할 필요가 없기 때문에 이것은 나에게 그리고 내 친구들이 만들고 디버깅할 대부분의 응용 프로그램에 대한 좋은 솔루션입니다. 나는 세그폴트를 일으킨 PID와 같은 것들을 포함하기 위해 이 답변을 좀 더 수정하고 싶습니다. 저와 제가 상상하는 많은 사람들에게는 확실히 충분할 것입니다.
마지막으로 덤프를 실제로 보려면 다음 명령을 실행하면 됩니다.
gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump
segfault를 가져오는 실행 파일을 컴파일/실행한 폴더에 있다고 가정합니다.