분할 오류 (코어 덤프 됨)-어디로? 뭐야? 그리고 왜?

다른 사람이 정리하면 …

… 일반적으로 아무것도 찾지 못합니다.하지만 다행스럽게도 Linux는 런타임에 지정할 수있는 핸들러입니다. /usr/src/linux/Documentation/sysctl/kernel.txt 에서 찾을 수 있습니다 :

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

• 패턴은 “|”이고 커널은 나머지 패턴을 실행할 명령으로 취급합니다. 코어 덤프는 파일 대신 해당 프로그램의 표준 입력에 기록됩니다.

( 감사합니다 )

A 소스에 따르면 이것은 abrt 프로그램 (중단이 아닌 자동 버그보고 도구)에 의해 처리되지만 제 아치 리눅스에서는 systemd에 의해 처리됩니다. 자신 만의 핸들러를 작성하거나 현재 디렉토리를 사용하고 싶을 수 있습니다.

하지만 거기에 무엇이 있습니까?

이제 여기에 포함 된 것은 시스템에 따라 다르지만 모든 것을 알고있는 백과 사전 :

[코어 덤프]는 작업 메모리의 기록 된 상태로 구성됩니다. 실제로는 프로그램 카운터와 스택 포인터, 메모리 관리 정보를 포함 할 수있는 프로세서 레지스터를 포함하여 프로그램 상태의 다른 핵심 부분이 일반적으로 동시에 덤프됩니다. 및 기타 프로세서 및 운영 체제 플래그 및 정보.

… 따라서 기본적으로 모든 gdb를 포함합니다. 원합니다.

예,하지만 gdb 대신 행복했으면합니다.

gdb는 실행 파일의 정확한 사본이있는 한 모든 코어 덤프를로드합니다 : gdb path/to/binary my/core.dump. 그러면 평상시처럼 업무를 계속할 수 있고 버그를 재현하지 않는 대신 버그 수정을 시도하고 실패함으로써 짜증을 낼 수 있습니다.

또한 ulimit -c가 0를 반환하면 코어 덤프 파일이 작성되지 않습니다.

리눅스 애플리케이션의 충돌로 생성 된 핵심 파일을 어디에서 검색 할 수 있습니까?

또한 CTRL – \ 를 사용하여 수동으로 코어 덤프를 트리거하면 프로세스가 종료되고 코어 덤프가 발생합니다.

코어 파일은 일반적으로 core라고하며 프로세스의 현재 작업 디렉토리에 있습니다. 그러나 코어 파일이 생성되지 않는 이유에 대한 긴 목록이 있으며, 다른 이름으로 완전히 다른 곳에있을 수 있습니다. 자세한 내용은 core.5 매뉴얼 페이지 를 참조하세요.

설명

특정 신호의 기본 동작은 프로세스를 종료하고 코어 덤프 파일 , a를 생성하도록하는 것입니다. 종료 시점의 프로세스 메모리 이미지를 포함하는 디스크 파일.이 이미지는 디버거 (예 : gdb (1))에서 종료 시점의 프로그램 상태를 검사하는 데 사용할 수 있습니다. 프로세스가 코어 덤프를 유발하는 신호 목록은 signal (7)에서 찾을 수 있습니다.

…

다양한 코어 덤프 파일이 생성되지 않는 상황 :

 * The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file will fail if the directory in which it is to be created is nonwritable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link). * A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file. * The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem. * The directory in which the core dump file is to be created does not exist. * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell"s ulimit command (limit in csh(1)). * The binary being executed by the process does not have read permission enabled. * The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).) * (Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option. 

또한, madvise ()가 발생하면 코어 덤프가 프로세스의 주소 공간 일부를 제외 할 수 있습니다. 2) MADV_DONTDUMP 플래그가 사용되었습니다.

코어 덤프 파일 이름 지정

기본적으로 코어 덤프 파일 core라는 이름이 지정되지만 / proc / sys / kernel / core_pattern 파일 (Linux 2.6 및 2.4.21 이후)은 코어 덤프 파일의 이름을 지정하는 데 사용되는 템플릿을 정의하도록 설정할 수 있습니다. 템플릿에는 코어 파일이 생성 될 때 다음 값으로 대체되는 % 지정자가 포함될 수 있습니다.

 %% a single % character %c core file size soft resource limit of crashing process (since Linux 2.6.24) %d dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7) %e executable filename (without path prefix) %E pathname of executable, with slashes ("/") replaced by exclamation marks ("!") (since Linux 3.0). %g (numeric) real GID of dumped process %h hostname (same as nodename returned by uname(2)) %i TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18) %I TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18) %p PID of dumped process, as seen in the PID namespace in which the process resides %P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12) %s number of signal causing dump %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) %u (numeric) real UID of dumped process 

Ubuntu에서 발생하는 모든 충돌은 / var / crash에 기록됩니다. 생성 된 충돌 보고서는 도구 apport

apport-unpack /var/crash/_crash_file.crash “path to unpack”을 사용하여 압축을 풀 수 있습니다.

그러면 압축을 푼 보고서의 코어 덤프를 읽을 수 있습니다.

gdb “cat ExecutablePath “CoreDump