코어 덤프 파일이 생성되지 않습니다.

코어 덤프 파일이 생성되지 않습니다.

---

내 응용 프로그램이 충돌 할 때마다 코어 덤프 파일이 생성되지 않습니다. 며칠 전에 다른 서버 에서 생성 된 것을 기억합니다 . 다음과 같이 bash에서 화면을 사용하여 앱을 실행하고 있습니다.

#!/bin/bash
ulimit -c unlimited
while true; do ./server; done

보시다시피 ulimit -c unlimited코어 덤프를 생성하려는 경우 중요한 것을 사용하고 있지만 세그먼트 오류가 발생하면 여전히 생성하지 않습니다. 어떻게 작동시킬 수 있습니까?

---

현재 디렉토리 (크래시시- server디렉토리가 변경 될 수 있음)가 쓰기 가능한지 확인하십시오 . 서버가를 호출 setuid하면 해당 사용자가 디렉토리에 쓸 수 있어야합니다.

또한 확인하십시오 /proc/sys/kernel/core_pattern. 코어 덤프를 다른 디렉토리로 리디렉션 할 수 있으며 해당 디렉토리는 쓰기 가능해야합니다. 여기에 더 많은 정보가 있습니다 .

---

이 링크 에는 코어 덤프가 생성되지 않는 좋은 체크리스트가 포함되어 있습니다.

• 코어는 전류 제한보다 컸을 것입니다.
• 코어 (디렉토리 및 파일)를 덤프하는 데 필요한 권한이 없습니다. 코어 덤프는 부모 프로세스와 다를 수있는 덤프 프로세스의 현재 디렉터리에 배치됩니다.
• 파일 시스템이 쓰기 가능하고 충분한 여유 공간이 있는지 확인하십시오.
• 작업 디렉토리에 core라는 하위 디렉토리가 있으면 코어가 덤프되지 않습니다.
• core라는 파일이 이미 존재하지만 여러 개의 하드 링크가있는 경우 커널은 코어를 덤프하지 않습니다.
• 실행 파일에 대한 권한을 확인합니다. 실행 파일에 suid 또는 sgid 비트가 활성화 된 경우 코어 덤프는 기본적으로 비활성화됩니다. 실행 권한이 있지만 파일에 대한 읽기 권한이없는 경우에도 마찬가지입니다.
• 프로세스가 작업 디렉토리, 코어 크기 제한 또는 덤프 가능 플래그를 변경하지 않았는지 확인하십시오.
• 일부 커널 버전은 공유 주소 공간 (AKA 스레드)이있는 프로세스를 덤프 할 수 없습니다. 최신 커널 버전은 이러한 프로세스를 덤프 할 수 있지만 파일 이름에 pid를 추가합니다.
• 실행 파일은 코어 덤프를 지원하지 않는 비표준 형식 일 수 있습니다. 각 실행 가능 형식은 코어 덤프 루틴을 구현해야합니다.
• 세분화 오류는 실제로 커널 일 수 있습니다. 죄송합니다. 시스템 로그에서 Oops 메시지를 확인하십시오.
• exit()코어 덤프 처리기를 사용하는 대신 호출 된 응용 프로그램 입니다.

---

서비스 에서 서버를 시작하는 경우 다른 bash 세션이 시작되므로 ulimit가 적용되지 않습니다. 이것을 스크립트 자체 에 넣으 십시오 .

ulimit -c unlimited

---

검사:

$ sysctl kernel.core_pattern

덤프가 생성되는 방법을 확인하십시오 (% e는 프로세스 이름이고 % t는 시스템 시간입니다).

당신이 우분투를 한 경우, 귀하의 덤프는에 의해 생성 apport에 /var/crash있지만 다른 형식 (편집을 볼 수있는 파일)입니다.

다음과 같이 테스트 할 수 있습니다.

sleep 10 &
killall -SIGSEGV sleep

코어 덤프가 성공하면 세그멘테이션 오류 표시 후에 "(코어 덤프 됨)"이 표시됩니다.

더 읽어보기 :

Ubuntu에서 코어 덤프 파일을 생성하는 방법

---

우분투

자세한 내용은 다음을 참조하십시오.

https://wiki.ubuntu.com/Apport

---

기록을 위해 Debian 9 Stretch ( systemd)에서 패키지를 설치해야했습니다 systemd-coredump. 그 후 폴더에 코어 덤프가 생성되었습니다 /var/lib/systemd/coredump.

또한 이러한 코어 덤프는 lz4형식으로 압축 됩니다. 압축을 풀려면 다음 liblz4-tool과 같은 패키지를 사용할 수 있습니다 lz4 -d FILE..

를 사용하여 압축 해제 된 코어 덤프를 디버깅 할 수 있으 gdb려면 완전히 긴 파일 이름을 더 짧은 이름으로 변경해야했습니다.

---

또한 /var/core코어 덤프가 기록 되는 위치 나 위치 에 충분한 디스크 공간이 있는지 확인하십시오 . 파티션이 꽉 찼거나 디스크 사용량이 100 %이면 문제가됩니다. 내 코어 덤프는 평균 몇 기가이므로 파티션에서 사용 가능한 최소 5-10 기가 있어야합니다.

---

여기에 제공된 답변은 코어 덤프가 생성되지 않은 대부분의 시나리오를 다룹니다. 그러나 제 경우에는 이들 중 어느 것도 적용되지 않았습니다. 이 답변을 다른 답변에 추가하여 게시하고 있습니다.

If your core file is not being created for whatever reason, I recommend looking at the /var/log/messages. There might be a hint in there to why the core file is not created. In my case there was a line stating the root cause:

Executable '/path/to/executable' doesn't belong to any package

To work around this issue edit /etc/abrt/abrt-action-save-package-data.conf and change ProcessUnpackaged from 'no' to 'yes'.

ProcessUnpackaged = yes

This setting specifies whether to create core for binaries not installed with package manager.

---

If you call daemon() and then daemonize a process, by default the current working directory will change to /. So if your program is a daemon then you should be looking for a core in / directory and not in the directory of the binary.

---

If one is on a Linux distro (e.g. CentOS, Debian) then perhaps the most accessible way to find out about core files and related conditions is in the man page. Just run the following command from a terminal:

man 5 core

---

Although this isn't going to be a problem for the person who asked the question, because they ran the program that was to produce the core file in a script with the ulimit command, I'd like to document that the ulimit command is specific to the shell in which you run it (like environment variables). I spent way too much time running ulimit and sysctl and stuff in one shell, and the command that I wanted to dump core in the other shell, and wondering why the core file was not produced.

I will be adding it to my bashrc. The sysctl works for all processes once it is issued, but the ulimit only works for the shell in which it is issued (maybe also the descendents too) - but not for other shells that happen to be running.

---

Note: If you have written any crash handler yourself, then the core might not get generated. So search for code with something on the line:

signal(SIGSEGV, <handler> );

so the SIGSEGV will be handled by handler and you will not get the core dump.

---

Just in case someone else stumbles on this. I was running someone else's code - make sure they are not handling the signal, so they can gracefully exit. I commented out the handling, and got the core dump.

---

In centos,if you are not root account to generate core file: you must be set the account has a root privilege or login root account:

vim /etc/security/limits.conf

account soft core unlimited
account hard core unlimited

then if you in login shell with securecrt or other:

logout and then relogin

ReferenceURL : https://stackoverflow.com/questions/7732983/core-dump-file-is-not-generated