Errore di segmentazione (core scaricato) - dove? che cos'è? e perché?


16

Quando si verifica un errore di segmentazione in Linux, il messaggio di errore Segmentation fault (core dumped)verrà stampato sul terminale (se presente) e il programma verrà terminato. Come sviluppatore C / C ++, questo mi succede abbastanza spesso, e di solito lo ignoro e mi sposto gdb, ricreando la mia azione precedente per attivare nuovamente il riferimento di memoria non valido. Invece, ho pensato che avrei potuto forse usare questo "core", dato che correre gdbtutto il tempo è piuttosto noioso e non riesco sempre a ricreare l'errore di segmentazione.

Le mie domande sono tre:

  • Dove viene scaricato questo "nucleo" sfuggente?
  • Cosa contiene?
  • Cosa posso farci?

Di solito è necessario solo il comando gdb path-to-your-binary path-to-corefile, quindi info stackseguito da Ctrl-d. L'unica cosa preoccupante è che il dumping core è una cosa normale per te.
ott--

Non molto al solito , più occasionale - il più delle volte è dovuto a errori di battitura o qualcosa che ho cambiato e non ho impedito il risultato.
Joe,

Risposte:


16

Se altre persone puliscono ...

... di solito non trovi niente. Ma per fortuna Linux ha un gestore per questo che puoi specificare in fase di esecuzione. In /usr/src/linux/Documentation/sysctl/kernel.txt troverai:

[/ proc / sys / kernel /] core_pattern viene utilizzato per specificare un nome di modello di file di dump principale.

  • Se il primo carattere del pattern è un '|', il kernel tratterà il resto del pattern come un comando da eseguire. Il dump principale verrà scritto nell'input standard di quel programma anziché in un file.

( grazie )

Secondo la fonte, questo è gestito dal abrtprogramma (ovvero Automatic Bug Reporting Tool, non abort), ma sul mio Arch Linux è gestito da systemd. Si consiglia di scrivere il proprio gestore o utilizzare la directory corrente.

Ma cosa c'è dentro?

Ora ciò che contiene è specifico del sistema, ma secondo l'enciclopedia onnisciente :

[Un core dump] è costituito dallo stato registrato della memoria di lavoro di un programma per computer in un momento specifico [...]. In pratica, altri elementi chiave dello stato del programma vengono generalmente scaricati contemporaneamente, inclusi i registri del processore, che possono includere il contatore del programma e il puntatore dello stack, informazioni sulla gestione della memoria e altri flag e informazioni sul processore e sul sistema operativo.

... quindi contiene praticamente tutto ciò gdbche si può desiderare e altro ancora.

Sì, ma vorrei che fossi felice invece di gdb

Si può essere entrambi felici poiché gdbcaricherà ogni core dump finché si dispone di una copia esatta del file eseguibile: gdb path/to/binary my/core.dump. Dovresti quindi essere in grado di continuare gli affari come al solito ed essere infastidito provando e non riuscendo a correggere i bug invece di provare e non riuscire a riprodurre i bug.



4

Il file core viene normalmente chiamato coree si trova nella directory di lavoro corrente del processo. Tuttavia, esiste un lungo elenco di motivi per cui un file core non verrebbe generato e potrebbe trovarsi da qualche altra parte, con un nome diverso. Vedi la pagina man core.5 per i dettagli:

DESCRIZIONE

L'azione predefinita di alcuni segnali è quella di far terminare un processo e produrre un file di dump principale , un file su disco contenente un'immagine della memoria del processo al momento della conclusione. Questa immagine può essere utilizzata in un debugger (ad esempio, gdb (1)) per ispezionare lo stato del programma al momento della sua conclusione. Un elenco dei segnali che causano il dump di un processo nel core può essere trovato nel segnale (7).

...

Esistono varie circostanze in cui non viene prodotto un file di dump principale:

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

Inoltre, un dump di core può escludere parte dello spazio degli indirizzi del processo se è stato utilizzato il flag madvise (2) MADV_DONTDUMP.

Denominazione dei file core di dump

Per impostazione predefinita, un file di dump principale è denominato core, ma il file / proc / sys / kernel / core_pattern (da Linux 2.6 e 2.4.21) può essere impostato per definire un modello utilizzato per denominare i file di dump principali. Il modello può contenere% specificatori che vengono sostituiti dai seguenti valori quando viene creato un file core:

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

In Ubuntu ogni incidente che si verifica viene registrato in / var / crash. Il rapporto sugli arresti anomali generato può essere decompresso utilizzando uno strumento apport

apport-unpack /var/crash/_crash_file.crash 'percorso per decomprimere'

e quindi il dump principale nel report decompresso può essere letto usando

gdb 'cat ExecutablePath' CoreDump

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.