it-swarm.com.de

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

Während der Ausführung eines C-Programms wird "(core dumped)" angezeigt, aber unter dem aktuellen Pfad werden keine Dateien angezeigt.

Ich habe das ulimit gesetzt und verifiziert:

ulimit -c unlimited 
ulimit -a 

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

253
webminal.org

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

[/ proc/sys/kernel /] core_pattern wird verwendet, um einen Namen für das Core-Dumpfile-Muster anzugeben.

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

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

In jedem Fall lautet die schnelle Antwort, dass Sie Ihre Kerndatei in /var/cache/abrt Finden sollten, wo abrt sie nach dem Aufrufen speichert. In ähnlicher Weise können andere Systeme, die Apport verwenden, Kerne in /var/crash Und so weiter abfangen.

227
ephemient

Unter Ubuntu der letzten Zeit (in meinem Fall 12.04) kann "Segmentierungsfehler (Core Dumped)" gedruckt werden, es wird jedoch keine Core-Datei erstellt, in der Sie möglicherweise eine erwarten (zum Beispiel für ein lokal kompiliertes Programm).

Dies kann passieren, wenn Sie eine Kerndateigröße von 0 haben (Sie haben ulimit -c unlimited Noch nicht getan) - 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 /proc/sys/kernel/core_pattern An Apport (Ubuntus Absturzmeldesystem) weitergeleitet scheint die irreführende Nachricht 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 in /var/log/apport.log Zu sehen ist), wird das Standardverhalten des Kernels beim Ablegen einer Kerndatei im cwd simuliert ( Dies geschieht im Skript /usr/share/apport/apport). Dies schließt das Einhalten von ulimit ein. In diesem Fall wird nichts unternommen. Aber (ich nehme an) für den Kernel wurde ein Corefile generiert (und an Apport weitergeleitet), daher die Meldung "Segmentation fault (core dumped)".

Letztendlich hatte PEBKAC vergessen, ein Limit zu setzen, aber die irreführende Botschaft ließ mich denken, ich würde eine Weile verrückt werden und mich fragen, was meine Corefiles fressen würde.

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

206
jtn

Mit dem Start von systemd gibt es auch ein anderes Szenario. Standardmäßig speichert systemd Speicherabbilder in seinem Journal, auf die mit dem Befehl systemd-coredumpctl 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 größer sein als die Größe des zu sichernden Core, wie zum Beispiel durch ulimit -c unlimited.

75
timss

Anweisungen schreiben, um einen Core-Dump unter Ubuntu 16.04 LTS zu erhalten:

  1. Wie @jtn in seiner Antwort erwähnt hat, delegiert Ubuntu die Anzeige von Abstürzen an apport , das sich wiederum weigert, den Dump zu schreiben, da das Programm kein installiertes Paket ist. Before making changes

  2. Um das Problem zu beheben, müssen wir sicherstellen, dass apport Core-Dump-Dateien auch für Nicht-Paket-Programme schreibt. Erstellen Sie dazu eine Datei mit dem Namen ~/.config/apport/settings mit folgendem Inhalt:
    [main] unpackaged=true

  3. Führen Sie nun erneut einen Programmabsturz durch und sehen Sie, wie Ihre Absturzdateien im folgenden Ordner erstellt werden: /var/crash mit Namen wie *. 1000.crash. Beachten Sie, dass diese Dateien nicht direkt von gdb gelesen werden können. After making changes
  4. [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

39
ankurrc

Ich könnte mir zwei Möglichkeiten vorstellen:

  1. Wie andere bereits ausgeführt haben, könnte das Programm chdir(). Darf der Benutzer, der das Programm ausführt, in das Verzeichnis schreiben, in das es chdir() geschrieben hat? Andernfalls kann der Core-Dump nicht erstellt werden.

  2. Aus irgendeinem seltsamen Grund heißt der Core-Dump nicht core.*. Sie können /proc/sys/kernel/core_pattern Darauf überprüfen. Außerdem würde der von Ihnen angegebene Befehl find keinen typischen Core-Dump finden. Sie sollten find / -name "*core.*" Verwenden, da der typische Name des Coredumps core.$PID Ist.

10
ahans

Wenn auf RHEL Core-Dumps für Binärdateien fehlen und wenn abrt verwendet wird, stellen Sie sicher, dass /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).

7
MRalwasser

Meine Bemühungen in der WSL waren erfolglos.

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

Die Kommentare weisen darauf hin

Dies ist ein bekanntes Problem, das wir kennen und das wir untersuchen.

Github Problem

Windows Developer Feedback

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 % nach `/ proc/sys/kernel/core_pattern '

3
mahaveer darade

ulimit -c unlimited hat die Core-Datei nach einem "Core Dump" korrekt im aktuellen Verzeichnis angezeigt.

0