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


16

Linux에서 분할 오류가 발생하면 오류 메시지 Segmentation fault (core dumped)가 터미널 (있는 경우)에 인쇄되고 프로그램이 종료됩니다. C / C ++ 개발자로서 이것은 종종 나에게 발생하며 일반적으로 무시하고 계속 진행 gdb하여 잘못된 메모리 참조를 다시 트리거하기 위해 이전 작업을 다시 만듭니다. 대신, gdb항상 실행 하는 것이 다소 번거로우므로이 "핵심"을 대신 사용할 수 있다고 생각 했으며, 항상 세분화 오류를 재현 할 수는 없습니다.

내 질문은 세 가지입니다.

  • 이 어려운 "핵심"은 어디에 버려 집니까?
  • 무엇이 포함되어 있습니까?
  • 그것으로 무엇을 할 수 있습니까?

일반적으로 명령이 필요하다가 gdb path-to-your-binary path-to-corefileinfo stack뒤에옵니다 Ctrl-d. 걱정되는 것은 코어 덤핑이 일반적인 것입니다.
ott--

별로 일상적이지 않고 더 간헐적이지 않습니다. 대부분의 경우 오타 나 내가 바꾼 것으로 인해 결과가 선점되지 않았습니다.
Joe

답변:


16

다른 사람들이 청소하면 ...

... 아무것도 찾지 못합니다. 운 좋게도 리눅스에는 런타임에 지정할 수있는 핸들러가 있습니다. /usr/src/linux/Documentation/sysctl/kernel.txt 에는 다음이 있습니다.

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

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

( 감사합니다 )

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

그러나 거기에 무엇이 있습니까?

이제 포함 된 것은 시스템마다 다르지만 모든 백과 사전 에 따르면 :

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

... 기본적으로 gdb원하는 모든 것을 포함 합니다.

그래,하지만 난 gdb 대신 행복하길 바래

gdb실행 파일의 정확한 사본이있는 한 코어 덤프를로드 하므로 두 가지 모두 만족할 수 있습니다 gdb path/to/binary my/core.dump. 그런 다음 평상시처럼 비즈니스를 계속할 수 있어야하며 버그를 재생산하지 않고 버그를 수정하려고 시도하면 실패합니다.



4

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

기술

특정 신호의 기본 동작은 종료하고 생산하는 과정 일으킬 것입니다 코어 덤프 파일 , 종료시 프로세스의 메모리의 이미지를 포함하는 디스크 파일을. 이 이미지는 디버거 (예 : 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

2

우분투에서 발생하는 충돌은 / var / crash에 로그인됩니다. 생성 된 충돌 보고서는 도구 apport를 사용하여 포장을 풀 수 있습니다.

apport-unpack /var/crash/_crash_file.crash '포장 풀기 경로'

그런 다음 압축을 푼 보고서의 코어 덤프를 사용하여 읽을 수 있습니다.

gdb 'cat ExecutablePath'CoreDump

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.