Falha de segmentação (núcleo despejado) - para onde? O que é isso? e porque?

Question

Quando ocorre uma falha de segmentação no Linux, a mensagem de erro Segmentation fault (core dumped) será impressa no terminal (se houver) e o programa será finalizado. Como um dev de C / C ++, isso acontece comigo com bastante frequência, e eu geralmente o ignoro e movo para gdb , recriando minha ação anterior para acionar novamente a referência de memória inválida. Em vez disso, achei que talvez pudesse usar esse "core" em vez disso, já que executar gdb todo o tempo é bastante entediante e nem sempre posso recriar a falha de segmentação.

Minhas perguntas são três:

• Onde esse "núcleo" indescritível é descartado?
• O que ele contém?
• O que posso fazer com isso?

Answer 1

Se outras pessoas limparem ...

... você geralmente não encontra nada. Mas, felizmente, o Linux tem um manipulador para isso que você pode especificar em tempo de execução. Em /usr/src/linux/Documentation/sysctl/kernel.txt , você encontrará:

[/proc/sys/kernel/]core_pattern is used to specify a core dumpfile pattern name.

• If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file.

( obrigado )

De acordo com a fonte, isso é tratado pelo programa abrt (que é a Ferramenta de Relatório Automático de Bugs, não para abortar), mas no meu Arch Linux ele é tratado pelo systemd. Você pode escrever seu próprio manipulador ou usar o diretório atual.

Mas o que tem lá?

Agora, o que ele contém é específico do sistema, mas de acordo com a a enciclopédia que tudo conhece :

[A core dump] consists of the recorded state of the working memory of a computer program at a specific time[...]. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information.

... então basicamente contém tudo que gdb queria, e mais.

Sim, mas gostaria que eu ficasse feliz em vez de gdb

Você pode estar feliz, pois gdb carregará qualquer dump principal contanto que você tenha uma cópia exata do seu executável: gdb path/to/binary my/core.dump . Você deve, então, ser capaz de continuar os negócios como de costume e ficar incomodado tentando e não consertando os erros, em vez de tentar e não conseguir reproduzir os erros.

    

Answer 2

O arquivo principal normalmente é chamado de core e está localizado no diretório de trabalho atual do processo. No entanto, há uma longa lista de motivos pelos quais um arquivo principal não seria gerado e pode estar localizado em outro lugar, sob um nome diferente. Veja a página man core.5 para detalhes:

DESCRIPTION

The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory at the time of termination. This image can be used in a debugger (e.g., gdb(1)) to inspect the state of the program at the time that it terminated. A list of the signals which cause a process to dump core can be found in signal(7).

...

There are various circumstances in which a core dump file is not produced:

   *  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.

In addition, a core dump may exclude part of the address space of the process if the madvise(2) MADV_DONTDUMP flag was employed.

Naming of core dump files

By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define a template that is used to name core dump files. The template can contain % specifiers which are substituted by the following values when a core file is created:

       %%  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

    

Answer 3

Além disso, se ulimit -c retornar 0 , nenhum arquivo de despejo principal será gravado.

Veja Onde procurar o arquivo principal gerado pelo travamento de um aplicativo linux?

Você também pode disparar um core dump manualmente com CTRL - \ que encerra o processo e causa um dump principal.

    

Answer 4

No Ubuntu, qualquer falha que ocorrer é registrada em / var / crash. O relatório de falha gerado pode ser descompactado usando um apport de ferramenta

apport-unpack /var/crash/_crash_file.crash 'path to unpack'

e, em seguida, o dump principal no relatório descompactado pode ser lido usando

gdb 'cat ExecutablePath' CoreDump