Core scaricato, ma il file core non si trova nella directory corrente?

Durante l'esecuzione di un programma C, dice "(core dumped)" ma non riesco a vedere alcun file nel percorso corrente.

Ho impostato e verificato il ulimit:

ulimit -c unlimited 
ulimit -a 

Ho anche provato a trovare un file chiamato "core", ma non hai ottenuto il file di core dump?
Qualche aiuto, dov'è il mio file principale?

Leggi /usr/src/linux/Documentation/sysctl/kernel.txt .

[/ 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.

Invece di scrivere il dump principale su disco, il sistema è configurato per inviarlo al abrtprogramma. Lo strumento di segnalazione automatica dei bug non è probabilmente documentato come dovrebbe essere ...

In ogni caso, la risposta rapida è che dovresti essere in grado di trovare il tuo file principale /var/cache/abrt, dove lo abrtmemorizza dopo essere stato invocato. Allo stesso modo, altri sistemi che utilizzano Apport possono eliminare i core /var/crashe così via.

Su Ubuntu recente (12.04 nel mio caso), è possibile stampare "Errore di segmentazione (core dumped)", ma non viene prodotto alcun file core dove ci si potrebbe aspettare uno (ad esempio per un programma compilato localmente).

Questo può accadere se hai un ulimit di dimensione del file core pari a 0 (non lo hai fatto ulimit -c unlimited) - questo è il valore predefinito su Ubuntu. Normalmente ciò sopprimerebbe il "(core dumped)", inducendoti nel tuo errore, ma su Ubuntu, i corefile vengono inviati ad Apport (il sistema di segnalazione degli arresti anomali di Ubuntu) tramite /proc/sys/kernel/core_pattern, e questo sembra causare il messaggio fuorviante.

Se Apport scopre che il programma in questione non è quello per cui dovrebbe riportare arresti anomali (di cui puoi vedere che sta succedendo /var/log/apport.log), ricade nella simulazione del comportamento predefinito del kernel di mettere un file core nel CWD (questo viene fatto nello script /usr/share/apport/apport). Questo include onorare ulimit, nel qual caso non fa nulla. Ma (suppongo) per quanto riguarda il kernel, è stato generato un file core (e inviato ad apportato), da cui il messaggio "Errore di segmentazione (core scaricato)".

Alla fine PEBKAC per aver dimenticato di impostare ulimit, ma il messaggio fuorviante mi fece pensare che stavo diventando pazzo per un po ', chiedendomi cosa stesse mangiando i miei corefile.

(Inoltre, in generale, la pagina del manuale core (5) - man 5 core- è un buon riferimento per dove finisce il tuo file core e per quali motivi potrebbe non essere scritto.)

Con il lancio di systemd , c'è anche un altro scenario. Di default systemd memorizzerà i dump principali nel suo journal, essendo accessibile con il systemd-coredumpctlcomando. Definito nel file core_pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Questo comportamento può essere disabilitato con un semplice "hack":

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

Come sempre, la dimensione dei core dump deve essere uguale o superiore alla dimensione del core che viene scaricato, come fatto per esempio ulimit -c unlimited.

Scrivere istruzioni per ottenere un dump di base in Ubuntu 16.04 LTS :

1. Come ha detto @jtn nella sua risposta, Ubuntu delega la visualizzazione degli arresti anomali a apport , che a sua volta rifiuta di scrivere il dump perché il programma non è un pacchetto installato.

2. Per risolvere il problema, dobbiamo assicurarci che apport scriva i file core di dump anche per i programmi non pacchetto . Per fare ciò, crea un file chiamato ~ / .config / apport / settings con i seguenti contenuti:
   [main] unpackaged=true

3. Ora blocca di nuovo il programma e vedi i tuoi file di crash generati nella cartella: / var / crash con nomi come * .1000.crash . Nota che questi file non possono essere letti direttamente da gdb .

4. [Opzionale] Per rendere leggibili i dump da gdb, eseguire il comando seguente:

   apport-unpack <location_of_report> <target_directory>

Riferimenti: Core_dump - Oracle VM VirtualBox

Potrei pensare a due seguenti possibilità:

1. Come altri hanno già sottolineato, il programma potrebbe chdir(). L'utente che esegue il programma è autorizzato a scrivere nella directory in cui è stato chdir()editato? In caso contrario, non è possibile creare il dump principale.

2. Per qualche strana ragione il dump principale non ha un nome core.*Puoi verificarlo /proc/sys/kernel/core_pattern. Inoltre, il comando find che hai nominato non trova un tipico dump del core. Dovresti usare find / -name "*core.*", come è il nome tipico del coredumpcore.$PID

Se ti mancano i core dump per i binari su RHELe durante l'utilizzo abrt, assicurati/etc/abrt/abrt-action-save-package-data.conf

contiene

ProcessUnpackaged = yes

Ciò consente la creazione di rapporti sugli arresti anomali (inclusi core dump) per i file binari che non fanno parte dei pacchetti installati (ad esempio, creati localmente).

Per fedora25, ho trovato il file core su

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

dove ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %secondo `/ proc / sys / kernel / core_pattern '

I miei sforzi in WSL non hanno avuto successo.

Per coloro che eseguono il sottosistema Windows per Linux (WSL) sembra esserci un problema aperto in questo momento per i file di dump core mancanti.

I commenti indicano che

Questo è un problema noto di cui siamo a conoscenza, è qualcosa su cui stiamo indagando.

Problema di Github

Feedback degli sviluppatori di Windows

In Ubuntu18.04, il modo più semplice per ottenere un file core è inserire il comando seguente per interrompere il servizio apport.

sudo service apport stop

Quindi riesegui l'applicazione, otterrai il file di dump nella directory corrente.

Sono su Linux Mint 19 (basato su Ubuntu 18). Volevo avere coredumpfile nella cartella corrente. Ho dovuto fare due cose:

1. Cambia /proc/sys/kernel/core_pattern(di # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patterno di# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. Aumentare il limite per la dimensione del file core di $ ulimit -c unlimited

Questo è stato già scritto nelle risposte, ma ho scritto per riassumere brevemente. Il limite che cambia in modo interessante non richiede privilegi di root (come da /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root può solo abbassare il limite, quindi era inaspettato - i commenti sono ben accetti).

ulimit -c unlimited fatto apparire correttamente il file core nella directory corrente dopo un "core dump".