Ошибка сегментации (ядро сброшено) - куда? что это? и почему?

При возникновении ошибки сегментации в Linux сообщение об ошибке Segmentation fault (core dumped)будет распечатано на терминал (если есть), и программа будет завершена. Как разработчик C / C ++, это случается со мной довольно часто, и я обычно игнорирую это и перехожу на него gdb, воссоздавая свое предыдущее действие, чтобы снова вызвать недействительную ссылку на память. Вместо этого я подумал, что, возможно, смогу использовать вместо этого это «ядро», так как работа gdbвсе время довольно утомительна, и я не всегда могу воссоздать ошибку сегментации.

У меня три вопроса:

• Куда сбрасывается это неуловимое «ядро»?
• Что это содержит?
• Что я могу с этим сделать?

Если другие люди убираются ...

... ты обычно ничего не находишь. Но, к счастью, в Linux есть обработчик, который вы можете указать во время выполнения. В /usr/src/linux/Documentation/sysctl/kernel.txt вы найдете:

[/ proc / sys / kernel /] core_pattern используется для указания имени шаблона файла дампа ядра.

• Если первый символ шаблона - «|», ядро ​​будет рассматривать оставшуюся часть шаблона как команду для запуска. Дамп ядра будет записан в стандартный ввод этой программы, а не в файл.

( спасибо )

Согласно источнику, это обрабатывается abrtпрограммой (это инструмент автоматического сообщения об ошибках, а не прерывание), но в моем Arch Linux это обрабатывается systemd. Вы можете написать свой собственный обработчик или использовать текущий каталог.

Но что там?

Теперь то, что он содержит, зависит от системы, но согласно всезнающей энциклопедии :

[Дамп ядра] состоит из записанного состояния рабочей памяти компьютерной программы в определенное время [...]. На практике другие ключевые части состояния программы обычно сбрасываются одновременно, включая регистры процессора, которые могут включать в себя счетчик программ и указатель стека, информацию управления памятью и другие флаги и информацию процессора и операционной системы.

... так что он в основном содержит все, что gdbхотел, и даже больше.

Да, но я бы хотел, чтобы я был счастлив вместо GDB

Вы можете как быть счастливым , поскольку gdbбудет загружать любой дамп до тех пор , пока у вас есть точная копия исполняемого файла: gdb path/to/binary my/core.dump. После этого вы сможете продолжать работать как обычно и испытывать раздражение, пытаясь и не исправляя ошибки, а не пытаясь воспроизвести ошибки.

Кроме того, если ulimit -cвозвращается 0, то файл дампа памяти не будет записан.

См. Где искать файл ядра, сгенерированный в результате сбоя приложения Linux?

Вы также можете запустить дамп ядра вручную с помощью CTRL-, \который завершает процесс и вызывает дамп ядра.

Основной файл обычно coreвызывается и находится в текущем рабочем каталоге процесса. Однако существует длинный список причин, по которым основной файл не будет сгенерирован, и он может быть расположен где-то еще целиком под другим именем. Смотрите man-страницу core.5 для деталей:

ОПИСАНИЕ

Действие по умолчанию для определенных сигналов является причиной процесса прекратить и произвести дамп ядра , дисковый файл , содержащий образ памяти процесса на момент расторжения договора. Этот образ можно использовать в отладчике (например, gdb (1)) для проверки состояния программы в момент ее завершения. Список сигналов, которые вызывают процесс, чтобы сбросить ядро, может быть найден в сигнале (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_DONTDUMP madvise (2).

Наименование файлов дампа ядра

По умолчанию файл дампа ядра называется 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 'путь к распаковке'

а затем дамп ядра в распакованном отчете можно прочитать, используя

gdb 'cat ExecutablePath' CoreDump