코어가 덤프되었지만 코어 파일이 현재 디렉토리에 없습니까?

C 프로그램을 실행하는 동안 "(core dumped)"라고 표시됩니다. 되지만 현재 경로 아래에 파일이 없습니다.

나는 다음을 설정하고 확인했다 ulimit.

ulimit -c unlimited 
ulimit -a 

또한 "core"라는 파일을 찾으려고했지만 코어 덤프 파일을 얻지 못했습니까?
핵심 파일이 어디에 있습니까?

/usr/src/linux/Documentation/sysctl/kernel.txt를 읽으십시오 .

[/ proc / sys / kernel /] core_pattern은 코어 덤프 파일 패턴 이름을 지정하는 데 사용됩니다.

• 패턴의 첫 문자가 '|'이면 커널은 나머지 패턴을 실행할 명령으로 처리합니다. 코어 덤프는 파일 대신 해당 프로그램의 표준 입력에 작성됩니다.

코어 덤프를 디스크에 쓰는 대신 시스템이이를 디스크로 abrt프로그램 으로 보내도록 구성되어 있습니다. 자동 버그보고 도구는 가능성 등이 문서화되지 해야 할 ...

어떤 경우에는, 빠른 응답은 당신이 당신의 코어 파일을 찾을 수 있어야한다는 것입니다 /var/cache/abrt경우, abrt호출되는 저장합니다 후를. 마찬가지로, Apport를 사용하는 다른 시스템 은에서 코어를 다람쥐로 제거 할 수 있습니다 /var/crash.

최근 우분투 (필자의 경우 12.04)에서 "세그먼트 결함 (코어 덤프)"이 인쇄 될 수 있지만 로컬 파일이 컴파일 된 프로그램과 같이 예상되는 위치에 코어 파일이 생성되지 않습니다.

코어 파일 크기 ulimit가 0 인 경우 (아직 수행하지 않은 경우) 이런 상황이 발생할 수 있습니다. 이것은 ulimit -c unlimited우분투의 기본값입니다. 일반적으로 "(core dumped)"를 억제하여 실수를 저 지르지 만 우분투에서는 코어 파일이를 통해 Apport (우분투의 충돌보고 시스템)에 파이프되어 /proc/sys/kernel/core_pattern오해의 소지가있는 것으로 보입니다.

Apport가 문제의 프로그램이 충돌을보고해야하는 것이 아니라는 것을 발견하면 (에서 발생하는 것을 볼 수 있음 /var/log/apport.log) 코어 파일을 cwd에 넣는 기본 커널 동작을 시뮬레이션하는 것으로 돌아갑니다 (스크립트에서 수행됨)/usr/share/apport/apport ). 여기에는 ulimit 적용이 포함되며,이 경우 아무 것도 수행하지 않습니다. 그러나 커널에 관한 한 코어 파일이 생성되어 (분류하기 위해 파이프 됨) "세그먼트 결함 (코어 덤프)"이라는 메시지가 표시됩니다.

궁극적으로 PEBKAC는 ulimit 설정을 잊어 버렸지 만 오해의 소지가있는 메시지는 내가 코어 파일을 무엇을 먹고 있었는지 궁금해 한동안 화가 났다고 생각했습니다.

(또한 일반적으로 core (5) 매뉴얼 페이지 man 5 core--는 코어 파일이 끝나는 위치와 파일이 작성되지 않는 이유에 대한 참조입니다.)

systemd 가 출시되면서 또 다른 시나리오도 있습니다. 기본적으로 systemd는 저널에 코어 덤프를 저장하며 systemd-coredumpctl명령 으로 액세스 할 수 있습니다 . core_pattern-file에 정의되어 있습니다.

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

이 동작은 간단한 "해킹"으로 비활성화 할 수 있습니다.

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

항상 그렇듯이 코어 덤프의 크기는 예를 들어 수행되는 것처럼 덤프중인 코어의 크기와 같거나 커야합니다 ulimit -c unlimited.

Ubuntu 16.04 LTS 에서 코어 덤프를 얻는 지침 작성 :

1. @jtn이 그의 답변에서 언급했듯이 우분투는 충돌 표시를 apport에 위임합니다. 이 프로그램은 설치된 패키지가 아니기 때문에 덤프 작성을 거부합니다.

2. 이 문제를 해결하려면 apport 가 패키지 가 아닌 프로그램에 대한 코어 덤프 파일도 작성 해야 합니다. 이렇게하려면 ~ / .config / apport / settings 라는 파일을 다음 내용으로 만듭니다 .
   [main] unpackaged=true

3. 이제 프로그램을 다시 크래시 하고 * .1000.crash 와 같은 이름의 / var / crash 폴더 내에 크래시 파일이 생성 되는지 확인하십시오 . gdb 는이 파일들을 직접 읽을 수 없습니다 .

4. [선택 사항] gdb가 덤프를 읽을 수있게하려면 다음 명령을 실행하십시오.

   apport-unpack <location_of_report> <target_directory>

참조 : Core_dump – Oracle VM VirtualBox

다음 두 가지 가능성을 생각할 수 있습니다.

1. 다른 사람들이 이미 지적했듯이 프로그램은 chdir(). 프로그램을 실행하는 사용자가 디렉토리에 쓸 chdir()수 있습니까? 그렇지 않으면 코어 덤프를 작성할 수 없습니다.

2. 이상한 이유로 코어 덤프의 이름이 지정되지 않았습니다 . core.*확인할 수 있습니다 /proc/sys/kernel/core_pattern. 또한 이름을 지정한 find 명령은 일반적인 코어 덤프를 찾지 못합니다. 당신은 사용해야 find / -name "*core.*"코어 덤프의 전형적인 이름 그대로,core.$PID

바이너리를 RHEL사용할 때와 사용할 때 바이너리에 대한 코어 덤프가 누락 된 경우 다음 abrt을 확인하십시오./etc/abrt/abrt-action-save-package-data.conf

포함

ProcessUnpackaged = yes

이렇게하면 설치된 패키지에 포함되지 않은 바이너리 (예 : 로컬 빌드)에 대한 충돌 보고서 (코어 덤프 포함)를 만들 수 있습니다.

fedora25의 경우 코어 파일을 찾을 수 있습니다.

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

여기서 ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %`이 / proc / sys / kernel / core_pattern '에 따라

WSL에서의 나의 노력은 실패했습니다.

Linux 용 Windows 서브 시스템 (WSL)에서 실행중인 사용자에게는 현재 누락 된 코어 덤프 파일에 대한 공개 문제가있는 것 같습니다.

의견은

이것은 우리가 알고있는 알려진 문제이며, 우리가 조사하고있는 것입니다.

Github 문제

Windows 개발자 피드백

Ubuntu18.04에서 코어 파일을 얻는 가장 쉬운 방법은 아래 명령을 입력하여 apport 서비스를 중지하는 것입니다.

sudo service apport stop

그런 다음 응용 프로그램을 다시 실행하면 현재 디렉토리에 덤프 파일이 생성됩니다.

Linux Mint 19 (Ubuntu 18 기반)를 사용하고 있습니다. coredump현재 폴더에 파일 을 갖고 싶었습니다 . 나는 두 가지 일을해야했다 :

1. 변경 /proc/sys/kernel/core_pattern에 의해 ( # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern또는으로# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. 코어 파일 크기 제한을 $ ulimit -c unlimited

그것은 이미 답변에 쓰여졌지만 간결하게 요약하기 위해 썼습니다. 흥미롭게도 한계를 변경하는 데 루트 권한이 필요하지 않았습니다 ( /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root) root는 한계를 낮출 수 있으므로 예상치 못한 의견이 있습니다.

ulimit -c unlimited "코어 덤프"후에 코어 파일이 현재 디렉토리에 올바르게 나타납니다.