Core ausgegeben, aber Core-Datei befindet sich nicht im aktuellen Verzeichnis?

276

Während eines C-Programms wird "(Core Dumped)" angezeigt, aber unter dem aktuellen Pfad werden keine Dateien angezeigt.

Ich habe Folgendes festgelegt und überprüft ulimit:

ulimit -c unlimited 
ulimit -a

Ich habe auch versucht, eine Datei mit dem Namen "core" zu finden, aber die Core-Dump-Datei nicht erhalten?
Hilfe, wo ist meine Kerndatei?

c linux coredump

— webminal.org
quelle

1

Ruft das Programm irgendwann chdir auf? Wenn ja, schauen Sie dort.

— William Pursell

2

Ändert das Programm sein Arbeitsverzeichnis? Schau da.

— Richard Pennington

Ich würde die gesamte Festplatte nach einer aktuellen Datei durchsuchen;)

— Hamish Grubijan

1

oops nein es ist nicht da ... Ich habe es überprüft ..program chdir to / mnt und / ich habe beide Verzeichnisse überprüft, konnte aber die Datei nicht finden. Ich habe sogar / -name "* core" gefunden. Auch das hat mir die Datei nicht gezeigt. Das Programm verwendet C + SQLite, während es Werte einfügt, die es Core-Dumps. Es sagte Assertion Error == 0 zum ersten Mal und Fehler = 101 zum zweiten Mal ..

— webminal.org

7

Ja, wenn Sie /proc/sys/kernel/core_patternmit einer Zeichenfolge überschreiben, die mit beginnt /tmp, werden Ihre Core-Dumps dort abgelegt.

— Ephemient

240

Lesen Sie /usr/src/linux/Documentation/sysctl/kernel.txt .

[/ proc / sys / kernel /] core_pattern wird verwendet, um einen Core-Dumpfile-Musternamen anzugeben.

Wenn das erste Zeichen des Musters ein '|' ist, behandelt der Kernel den Rest des Musters als einen auszuführenden Befehl. Der Core-Dump wird in die Standardeingabe dieses Programms anstatt in eine Datei geschrieben.

Anstatt den Core-Dump auf die Festplatte zu schreiben, ist Ihr System so konfiguriert, dass er ihn abrtstattdessen an das Programm sendet . Das Automated Bug Reporting Tool ist möglicherweise nicht so dokumentiert, wie es sein sollte ...

In jedem Fall lautet die schnelle Antwort, dass Sie in der Lage sein sollten, Ihre Kerndatei zu finden /var/cache/abrt, in der abrtsie nach dem Aufruf gespeichert wird. In ähnlicher Weise können andere Systeme, die Apport verwenden, Kerne entfernen /var/crashund so weiter.

— kurzlebig
quelle

30

Ja, ich habe core_pattern mit dem folgenden Inhaltsecho "core.% e.% p"> / proc / sys / kernel / core_pattern bearbeitet. Jetzt wird die Core-Dump-Datei im aktuellen Verzeichnis selbst erstellt. mit dem Namen "core.giis.12344" usw. Vielen Dank für Ihre Antworten / Kommentare / Hinweise.

— webminal.org

20

Nur um zu beachten, dass Fedora 18 abrt Programm Core Dumps in /var/spool/abrt/statt/var/cache/abrt

— Nelson

4

Gibt es eine Möglichkeit, Benutzern zu ermöglichen, dies für sich selbst zu konfigurieren, anstatt dass jeder die Systemkonfiguration verwenden muss?

— Allyourcode

Wenn dieser Befehl ausgeführt und der Prozess aufgerufen wird, werden stdout und stderr nicht standardmäßig geöffnet? Ich sehe sehr seltsame Dinge geschehen. Wenn ich dup2 von stderr und stdout in meiner benutzerdefinierten Datei (applog.txt) verwende, werden Daten, die ich in eine andere Datei (mycore.BIN) schreibe, in eine Datei umgeleitet, mit der ich stdout & stderr (applog.txt) abgefangen habe. . Gibt es eine gute Lektüre darüber? Bitte vorschlagen. Vielen Dank

— mk ..

20

Systemd in Archlinux Store Coredumps in/var/lib/systemd/coredump/

— Francois

224

Unter Ubuntu (in meinem Fall 12.04) ist es möglich, dass "Segmentierungsfehler (Core Dumped)" gedruckt wird, aber keine Core-Datei erstellt wird, wo Sie eine erwarten könnten (zum Beispiel für ein lokal kompiliertes Programm).

Dies kann passieren, wenn Sie eine Kerndateigröße von 0 haben (Sie haben es noch nicht getan ulimit -c unlimited) - dies ist die Standardeinstellung unter Ubuntu. Normalerweise würde dies das "(Core Dumped)" unterdrücken und Sie auf Ihren Fehler hinweisen, aber unter Ubuntu werden Corefiles über an Apport (Ubuntus Crash Reporting System) weitergeleitet /proc/sys/kernel/core_pattern, und dies scheint die irreführende Meldung zu verursachen.

Wenn Apport feststellt, dass es sich bei dem fraglichen Programm nicht um ein Programm handelt, für das Abstürze gemeldet werden sollen (was Sie sehen können /var/log/apport.log), wird das Standard-Kernelverhalten beim Einfügen einer Kerndatei in das cwd simuliert (dies erfolgt im Skript)/usr/share/apport/apport ). Dies beinhaltet die Ehrung von ulimit. In diesem Fall wird nichts unternommen. Aber (ich nehme an) was den Kernel betrifft, wurde eine Corefile generiert (und an Apport weitergeleitet), daher die Meldung "Segmentierungsfehler (Core Dumped)".

Letztendlich PEBKAC, weil ich vergessen hatte, ulimit zu setzen, aber die irreführende Nachricht ließ mich denken, dass ich für eine Weile verrückt wurde und mich fragte, was meine Corefiles fraß.

(Im Allgemeinen ist die Handbuchseite zum Kern (5) - man 5 core- eine gute Referenz dafür, wo Ihre Kerndatei landet und warum sie möglicherweise nicht geschrieben wurde.)

— jtn
quelle

4

Vielen Dank - ich bin auf das gleiche Problem gestoßen. Übrigens zeigt Ubuntu 14.04 genau das gleiche Verhalten wie das von Ihnen beschriebene.

— Malte Skoruppa

5

Bei meiner Ubuntu-Installation (geändert am 14.04.) Gibt es eine einfache vorübergehende Problemumgehung, sudo service apport stopindem Sie /proc/sys/kernel/core_patternFolgendes ausführen: Nachdem ich das ausgeführt habe, wurde es von der Apport-Pipe auf "Just" geändert core. Apport ist klug genug, um das core_patternvorübergehend zu beheben , nehme ich an.

— Patrick Collins

6

"ulimit -c unlimited" ist genau das, was ich brauchte - Danke!

— Dave C

4

Ich habe jede zutreffende Antwort und jeden Ort in jedem Kommentar hier ausprobiert, nachdem ich den Befehl ulimit ausgeführt habe, kann aber immer noch keine Kerndatei auf meinem Ubuntu 16.04 LTS finden ...

— Nagev

2

@ElectricGoat Nein, habe ich nicht. Es ist schlechtes UX-Design, IMO. Das System sollte nur den Pfad drucken oder überhaupt keine Nachricht drucken, wenn sie nicht erstellt wird. Ich werde meine eigene Antwort hinzufügen, wann oder ob ich die Gelegenheit habe, dies weiter zu untersuchen.

— Nagev

80

Mit dem Start von systemd gibt es noch ein anderes Szenario. Standardmäßig speichert systemd Core-Dumps in seinem Journal, auf die mit dem systemd-coredumpctlBefehl zugegriffen werden kann . In der core_pattern-Datei definiert:

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

Dieses Verhalten kann mit einem einfachen "Hack" deaktiviert werden:

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

Wie immer muss die Größe der Core-Dumps gleich oder höher sein als die Größe des Core-Dumps, wie dies beispielsweise der Fall ist ulimit -c unlimited.

— timss
quelle

Dieser "Hack" hat bei mir nicht funktioniert (auch nach einem Neustart). Ich verwende Arch Linux und habe es bereits ausgeführt ulimit -c unlimited.

— Gsingh2011

@ gsingh2011 Es könnte veraltet sein. Ich führe Arch nicht mehr aus, daher kann ich nicht sagen, ob es heutzutage funktionieren soll. Wenn Sie es herausfinden, können Sie mich / uns mit einem neuen Kommentar aktualisieren.

— Timss

5

@ gsingh2011 Versuchen Sie 50-coredump.confstatt coredump.conf. Dies sollte überschreiben /lib/sysctl.d/50-coredump.conf. Die Standardeinstellung kann mitsysctl -w kernel.core_pattern=core

— Lekensteyn

Ich musste Appport ausschalten, damit dies funktioniertsudo service apport stop

— rahul003

51

Schreiben von Anweisungen zum Abrufen eines Core-Dumps unter Ubuntu 16.04 LTS :

Wie @jtn in seiner Antwort erwähnt hat, delegiert Ubuntu die Anzeige von Abstürzen an apport , was wiederum das Schreiben des Speicherauszugs verweigert, da das Programm kein installiertes Paket ist.
Um das Problem zu beheben, müssen wir sicherstellen, dass Apport auch Core-Dump-Dateien für Nicht-Paket- Programme schreibt . Erstellen Sie dazu eine Datei mit dem Namen ~ / .config / apport / settings mit folgendem Inhalt:
[main] unpackaged=true
Stürzen Sie nun Ihr Programm erneut ab und sehen Sie, wie Ihre Absturzdateien im folgenden Ordner generiert werden: / var / crash mit Namen wie * .1000.crash . Beachten Sie, dass diese Dateien nicht direkt von gdb gelesen werden können.
[Optional] Führen Sie den folgenden Befehl aus, um die Speicherauszüge von gdb lesbar zu machen:

apport-unpack <location_of_report> <target_directory>

Referenzen: Core_dump - Oracle VM VirtualBox

— ankurrc
quelle

3

Dies ist die einzige Lösung, die für mich in Ubuntu 18.04

— funktioniert hat

Welchen Benutzer betrifft ~ /? Wenn der Prozess von root ausgeführt wird, bedeutet das /root/.config/apport/settings?

— Nicholi

@Nicholi Ich glaube, es sollte der Benutzer sein, der das Programm ausgeführt hat. Ich bin mir aber nicht sicher.

— ankurrc

12

Ich könnte mir zwei Möglichkeiten vorstellen:

Wie andere bereits betont haben, könnte das Programm chdir(). Darf der Benutzer, der das Programm ausführt, in das Verzeichnis schreiben, in das es geschrieben wurde chdir()? Wenn nicht, kann der Core Dump nicht erstellt werden.
Aus irgendeinem seltsamen Grund wird der Core Dump nicht benannt core.* Sie können dies überprüfen /proc/sys/kernel/core_pattern. Außerdem würde der von Ihnen benannte Befehl find keinen typischen Core-Dump finden. Sie sollten verwenden find / -name "*core.*", wie der typische Name des Coredump istcore.$PID

— Ahans
quelle

Hier ist mein Muster - bedeutet dies, dass die Kerndatei so etwas wie "PID.signal.userid" anstelle von core.pid heißt? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

— webminal.org

9

Wenn Sie Core-Dumps für Binärdateien auf RHELund bei der Verwendung vermissen abrt, stellen Sie dies sicher/etc/abrt/abrt-action-save-package-data.conf

enthält

ProcessUnpackaged = yes

Dies ermöglicht die Erstellung von Absturzberichten (einschließlich Core-Dumps) für Binärdateien, die nicht Teil installierter Pakete sind (z. B. lokal erstellt).

— MRalwasser
quelle

6

Für fedora25 konnte ich die Kerndatei unter finden

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

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

— Mahaveer Darade
quelle

5

Meine Bemühungen in der WSL waren erfolglos.

Für diejenigen, die unter Windows Subsystem für Linux (WSL) ausgeführt werden, scheint derzeit ein offenes Problem für fehlende Core-Dump-Dateien zu bestehen.

Die Kommentare zeigen das an

Dies ist ein bekanntes Problem, dessen wir uns bewusst sind und das wir untersuchen.

Github-Problem

Windows-Entwickler-Feedback

— Brandon Søren Culley
quelle

5

In Ubuntu18.04 ist es am einfachsten, eine Kerndatei abzurufen, indem Sie den folgenden Befehl eingeben, um den Apportierungsdienst zu beenden.

sudo service apport stop

Führen Sie dann die Anwendung erneut aus. Sie erhalten eine Dump-Datei im aktuellen Verzeichnis.

— Nicolas Gong
quelle

3

Ich bin auf Linux Mint 19 (Ubuntu 18 basiert). Ich wollte coredumpDateien im aktuellen Ordner haben. Ich musste zwei Dinge tun:

Ändern /proc/sys/kernel/core_pattern(nach # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternoder nach# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
Erhöhung der Grenze für die Größe der Kerndatei um $ ulimit -c unlimited

Das wurde bereits in den Antworten geschrieben, aber ich schrieb, um es kurz zusammenzufassen. Interessanterweise erforderte das Ändern des Limits keine Root-Berechtigungen (gemäß /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root kann nur das Limit senken, was unerwartet war - Kommentare dazu sind willkommen).

— Marisha
quelle

2

ulimit -c unlimited Die Kerndatei wurde nach einem "Core Dump" korrekt im aktuellen Verzeichnis angezeigt.

— Nicolas VERHELST
quelle