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

Lesezeit: 10 Minuten

Benutzeravatar von webminal.org
webminal.org

Beim Ausführen eines C-Programms sagt es “(Core Dump)” aber ich kann keine Dateien unter dem aktuellen Pfad sehen.

Die habe ich eingestellt und überprüft ulimit:

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?
Irgendwelche Hilfe, wo ist meine Core-Datei?

  • Ruft das Programm irgendwann chdir auf? Wenn ja, schau dort nach.

    – William Pursel

    14. Januar 2010 um 17:03 Uhr

  • Ändert das Programm sein Arbeitsverzeichnis? Schau da.

    – Richard Pennington

    14. Januar 2010 um 17:03 Uhr

  • oops nein, es ist nicht da … Ich habe es überprüft. Ich habe sogar / -name “*core” gefunden. Auch dies zeigte mir die Datei nicht. Das Programm verwendet C + sqlite , während es Werte einfügt, die es Core-Dumps enthält.

    – webminal.org

    14. Januar 2010 um 17:25 Uhr

  • Ja, wenn Sie überschreiben /proc/sys/kernel/core_pattern mit einer Zeichenfolge, die mit beginnt /tmp dann werden Ihre Core-Dumps dorthin gehen.

    – vergänglich

    14. Januar 2010 um 20:43 Uhr

Benutzeravatar von ephemient
vergänglich

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

core_pattern wird verwendet, um den Musternamen einer Core-Dumpdatei anzugeben.

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

Anstatt den Core-Dump auf die Festplatte zu schreiben, ist Ihr System so konfiguriert, dass es ihn an den sendet abrt (Bedeutung: Automatisiertes Fehlermeldetool, nicht “abort”) Programm statt. Automatisiertes Tool zum Melden von Fehlern ist möglicherweise nicht so dokumentiert wie es sollte sein…

In jedem Fall lautet die schnelle Antwort, dass Sie in der Lage sein sollten, Ihre Kerndatei zu finden /var/cache/abrtwo abrt speichert es nach dem Aufruf. Ebenso verwenden andere Systeme Apportieren kann Kerne wegfetzen /var/crashusw.

  • ja, ich habe core_pattern mit folgendem Inhalt bearbeitet echo “core.%e.%p” > /proc/sys/kernel/core_pattern ..jetzt erstellt es die Core-Dump-Datei im aktuellen Verzeichnis selbst. mit dem Namen “core.giis.12344” usw. Vielen Dank für Ihre Antworten/Kommentare/Hinweise.

    – webminal.org

    15. Januar 2010 um 6:57 Uhr

  • Nur um anzumerken, dass das Fedora 18 Abrt-Programm Core-Dumps speichert /var/spool/abrt/ Anstatt von /var/cache/abrt

    – Nelson

    6. März 2013 um 9:31 Uhr


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

    – Allourcode

    17. Oktober 2013 um 19:57 Uhr

  • Wenn dieser Befehl ausgeführt und der Prozess aufgerufen wird, werden stdout und stderr standardmäßig nicht geöffnet? Ich sehe sehr seltsame Dinge passieren. 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) erfasst habe. . Gibt es dazu eine gute Lektüre? Bitte vorschlagen. Vielen Dank

    – Sandeep

    2. Juni 2014 um 7:53 Uhr

  • systemd in archlinux speichert Coredumps in /var/lib/systemd/coredump/

    – François

    21. Juni 2016 um 8:46 Uhr

Benutzeravatar von jtn
jtn

Bei aktuellem Ubuntu (in meinem Fall 12.04) ist es möglich, dass “Segmentation fault (core dumped)” gedruckt wird, aber keine Kerndatei erzeugt wird, wo Sie eine erwarten könnten (z. B. für ein lokal kompiliertes Programm).

Dies kann passieren, wenn Sie eine Core-Dateigröße ulimit von 0 haben (Sie haben es nicht getan ulimit -c unlimited) – dies ist die Standardeinstellung auf Ubuntu. Normalerweise würde das “(core dumped)” unterdrücken und Sie auf Ihren Fehler hinweisen, aber unter Ubuntu werden Corefiles weitergeleitet Apportieren (Ubuntus Absturzmeldesystem) via /proc/sys/kernel/core_patternund dies scheint die irreführende Meldung zu verursachen.

Wenn Apport feststellt, dass das fragliche Programm keins ist, sollte es Abstürze melden (was Sie in sehen können /var/log/apport.log), greift es auf die Simulation des standardmäßigen Kernel-Verhaltens zurück, bei dem eine Core-Datei in die cwd eingefügt wird (dies geschieht im script /usr/share/apport/apport). Dies schließt die Anerkennung von ulimit ein, in diesem Fall tut es nichts. Aber (ich nehme an), was den Kernel betrifft, wurde ein Corefile generiert (und an apport weitergeleitet), daher die Meldung “Segmentation fault (core dumped)”.

Letztendlich PEBKAC für das Vergessen, ulimit zu setzen, aber die irreführende Nachricht ließ mich eine Weile denken, ich würde verrückt werden und mich fragen, was meine Kerndateien frisst.

(Auch allgemein die Handbuchseite von core(5) — man 5 core — ist eine gute Referenz dafür, wo Ihre Kerndatei landet und warum sie möglicherweise nicht geschrieben wird.)

  • Vielen Dank – ich hatte genau das gleiche Problem. Ubuntu 14.04 zeigt übrigens genau das gleiche Verhalten wie das von Ihnen beschriebene.

    – Malte Skoruppa

    22. Juli 2015 um 10:19 Uhr

  • Bei meiner Ubuntu-Installation (geändert 14.04) gibt es eine einfache vorübergehende Problemumgehung dafür, indem sie ausgeführt wird sudo service apport stop — Nachdem ich das ausgeführt hatte, änderte es sich /proc/sys/kernel/core_pattern von der Apportleitung bis gerade core. Apport ist schlau genug, um das Problem zu beheben core_pattern vorübergehend, nehme ich an.

    – Patrick Collins

    22. Februar 2016 um 18:50 Uhr

  • “ulimit -c unlimited” ist genau das, was ich brauchte – Danke!

    – David C

    20. März 2016 um 18:07 Uhr

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

    – Nagev

    5. April 2017 um 13:39 Uhr

  • @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, wenn oder ob ich die Möglichkeit habe, dies weiter zu untersuchen.

    – Nagev

    17. August 2017 um 7:29 Uhr

Benutzeravatar von timss
Timss

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

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

Der einfachste Weg, um nach gespeicherten Core-Dumps zu suchen, ist über coredumpctl list (ältere Core-Dumps wurden möglicherweise automatisch entfernt). 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 von Core-Dumps gleich oder größer sein als die Größe des Cores, der ausgegeben wird, wie zum Beispiel von ulimit -c unlimited.

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

    – gsx

    16. Oktober 2013 um 5:15 Uhr


  • @ gsingh2011 Es könnte veraltet sein. Ich verwende Arch nicht mehr, daher kann ich nicht sagen, ob es heutzutage funktionieren sollte. Wenn Sie es herausfinden, können Sie mich/uns gerne mit einem neuen Kommentar aktualisieren.

    – timss

    16. Oktober 2013 um 10:58 Uhr

  • @gsingh2011 Versuchen Sie es 50-coredump.conf Anstatt von coredump.conf. Dies sollte außer Kraft gesetzt werden /lib/sysctl.d/50-coredump.conf. Der Standard kann mit wiederhergestellt werden sysctl -w kernel.core_pattern=core

    – Lekenstein

    15. November 2013 um 10:07 Uhr

  • Ich musste Appport deaktivieren, damit dies funktionierte sudo service apport stop

    – rahul003

    2. Februar 2018 um 0:06 Uhr

  • Auf Ubuntu 21.10 musste ich installieren systemd-coredump zuerst, bevor ich das bekommen konnte coredumpctl Befehl zu arbeiten. Danach war es einfach 😉

    – Oligofren

    27. April um 10:48 Uhr

Benutzeravatar von ankurrc
ankurrc

Schreiben von Anweisungen, um einen Core-Dump zu erhalten Ubuntu 16.04 LTS:

  1. Wie @jtn in seiner Antwort erwähnt hat, delegiert Ubuntu die Anzeige von Abstürzen an apportierendie sich wiederum weigert, den Dump zu schreiben, weil das Programm kein installiertes Paket ist. Bevor Sie Änderungen vornehmen

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

  3. Jetzt stürzen Sie Ihr Programm erneut ab und sehen, wie Ihre Absturzdateien im Ordner generiert werden: /var/crash mit Namen wie *.1000.Absturz. Beachten Sie, dass diese Dateien nicht gelesen werden können gdb direkt. Nach Änderungen
  4. [Optional] Führen Sie den folgenden Befehl aus, um die Dumps für gdb lesbar zu machen:

    apport-unpack <location_of_report> <target_directory>

Verweise:
Core_dump – Oracle-VM VirtualBox

Benutzeravatar von ahans
ahans

Mir fallen da zwei Möglichkeiten ein:

  1. Wie andere bereits darauf hingewiesen haben, könnte das Programm chdir(). Darf der Benutzer, der das Programm ausführt, in das Verzeichnis schreiben? chdir()‘ed zu? Andernfalls kann der Core-Dump nicht erstellt werden.

  2. Aus irgendeinem seltsamen Grund hat der Core-Dump keinen Namen core.* Du kannst nachschauen /proc/sys/kernel/core_pattern dafür. Außerdem würde der von Ihnen genannte find-Befehl keinen typischen Core-Dump finden. Du solltest benutzen find / -name "*core.*"wie der typische Name des Arbeitsspeicherauszugs lautet core.$PID

  • 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

    14. Januar 2010 um 17:55 Uhr

  • Wenn Inhalt der virtuellen Datei /proc/sys/kernel/core_pattern beginnt mit einem Pipe-Symbol | Die Datei wird nicht in die Datei geschrieben, die durch definiert ist core_pattern aber die Befehl definiert, nachdem das Pipe-Symbol gestartet wurde, und die Kerndatei wird in stdin dieses Programms geschrieben. Es liegt zu 100% am Programm, danach mit dem Inhalt der Kerndatei umzugehen.

    – Mikko Rantalainen

    20. September 2021 um 16:53 Uhr

  • Zu Punkt 1: Nein, das Programm erstellt keinen Core Dump; es würde ein sehen EPERM. Nur wenn das Programm den Fehler nicht korrekt behandelt, kann es zum Beenden gezwungen werden (um zu verhindern, dass noch mehr Unsinn passiert).

    – U. Windl

    5. Januar um 10:28 Uhr

Benutzeravatar von MRalwasser
MRalwasser

Wenn Sie Core-Dumps für Binärdateien auf vermissen RHEL und beim benutzen abrtStelle sicher das /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 gebaut).

  • 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

    14. Januar 2010 um 17:55 Uhr

  • Wenn Inhalt der virtuellen Datei /proc/sys/kernel/core_pattern beginnt mit einem Pipe-Symbol | Die Datei wird nicht in die Datei geschrieben, die durch definiert ist core_pattern aber die Befehl definiert, nachdem das Pipe-Symbol gestartet wurde, und die Kerndatei wird in stdin dieses Programms geschrieben. Es liegt zu 100% am Programm, danach mit dem Inhalt der Kerndatei umzugehen.

    – Mikko Rantalainen

    20. September 2021 um 16:53 Uhr

  • Zu Punkt 1: Nein, das Programm erstellt keinen Core Dump; es würde ein sehen EPERM. Nur wenn das Programm den Fehler nicht korrekt behandelt, kann es zum Beenden gezwungen werden (um zu verhindern, dass noch mehr Unsinn passiert).

    – U. Windl

    5. Januar um 10:28 Uhr

Benutzeravatar von Nicolas Gong
Nicolas Gong

In Ubuntu18.04 ist der einfachste Weg, eine Kerndatei zu erhalten, die Eingabe des folgenden Befehls, um den Apport-Dienst zu stoppen.

sudo service apport stop

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

  • Ich habe das versucht und bekommen /etc/init.d/apport: 68: /etc/init.d/apport: cannot create /proc/sys/fs/suid_dumpable: Operation not permitted kann die Absturzdateien immer noch nicht finden. habe ich schon eingestellt ulimit -c unlimited. Jemand erwähnte die /proc/sys/kernel/core_pattern, ich kann diese Datei nicht einmal sehen. Was sollte noch getan werden?

    – doraemon

    7. November 2020 um 3:15 Uhr


  • Entschuldigung, da ich das Problem nicht angetroffen habe, kann ich Ihnen keine gute Antwort geben. Ich denke jedoch, dass Sie das Wissen des Apport-Dienstes erlernen können, dann können Sie wissen, wo sich die Core-Dump-Datei befindet. Hier ist die Urkunde: https://wiki.ubuntu.com/Apport.

    – Nicolas Gong

    16. November 2020 um 3:43 Uhr

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

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy