Wie gdb gegen einen daemon in den hintergrund?

Ich versuche zu Debuggen eines server-ich schrieb mit gdb als es segfaults unter ganz bestimmten und sehr seltenen Bedingungen.

Gibt es eine Möglichkeit, ich kann den gdb im hintergrund laufen (über stillen oder im batch-Modus?), Folgen die Kinder (wie mein server ist ein daemon und löst sich von der Haupt-PID) und automatisch einen dump der Kern und der backtrace (zu einem bestimmten Datei), wenn das Programm abstürzt?

InformationsquelleAutor David Titarenco | 2010-01-12
  1. 7

    Warum nicht einfach den Prozess laufen interaktiv in einer persistenten screen-Sitzung? Warum muss es ein daemon beim Debuggen? Oder nur gdb in die screen-Sitzung und befestigen Sie es an den Laufenden Prozess (z.B. gdb /path/to/binary -p PID_of_binary) nach forks.

    • Dies ist eigentlich eine tolle Idee, keine Ahnung, warum ich nicht denken 😛 Danke für die Elementare Lösung!
    • +1 für tmux statt screen
    InformationsquelleAutor Andy Ross
  2. 8

    Vorausgesetzt Sie haben die entsprechenden Berechtigungen haben, können Sie den gdb anzuhängen, um jeden Prozess. Sie können es auf der Kommandozeile mit:

    gdb /path/to/binary _pid_

    oder innerhalb von gdb mit dem attach-Befehl:

    attach _pid_

    So, sobald Ihr daemon gestartet wurde, können Sie eine der folgenden Verfahren anfügen an die Letzte PID-Ihre daemon ausgeführt wird. Anbringen gdb Stoppt den Prozess, die Sie verfolgen, so dass Sie brauchen, um eine mit "weiter", um es neu zu starten.

    Weiß ich nicht, einen direkten Weg zu bekommen, gdb, um beliebige Befehle auszuführen, wenn das Programm abstürzt. Hier ist ein workaround, das ich denken kann:

    1. Erstellen und registrieren Sie einen signal-Handler für SIGSEGV.
    2. Sagen gdb nicht zu stoppen auf, dass das signal (handle SIGSEGV nostop)
    3. Ein breakpoint auf die erste Zeile in der signal-handler.
    4. Zuweisen Befehle an den Haltepunkt aus Schritt 3
    InformationsquelleAutor R Samuel Klatchko
  3. 3

    Ersten, würde ich Ihre setup-shell /Umgebung, um Ihnen einen core dump. In der bash:

    ulimit -c unlimited

    Sobald Sie den core-dump verwenden, können Sie den gdb zu prüfen, die stack-trace:

    gdb /path/to/app /path/to/core/file
    • Beachten Sie, dass die core-Datei nicht die gleiche Sache, wie mit der gleichen Prozess wurde unter dem debugger. Die core-Datei nicht erhalten Informationen über die offenen Dateideskriptoren oder memory-mapping Zustand. So dass nicht immer ein nützlicher Vorschlag.
    • Und Sie können keine Funktionen aufrufen, die im Programm definiert sind.
    InformationsquelleAutor Kaleb Pederson
  4. 2

    Wie generieren Sie einen stacktrace, wenn mein gcc-C++ - app stürzt ab Antwort auf diese Frage sollte das tun, was Sie wollen. (vorausgesetzt, Sie können änderungen in Ihrem code)

    InformationsquelleAutor rgngl
  5. 1

    Ich bin nicht wirklich ein gdb Experte, aber zwei Dinge in den Sinn kommen

    1. Tracepoints , die möglicherweise geben Sie die erforderlichen Informationen wie das Programm läuft oder
    2. Verwenden Sie gdb, die remote-debugging-Funktion zu Debuggen Sie das Programm, während es läuft als daemon.
    InformationsquelleAutor Noufal Ibrahim
  6. 1

    Möchten Sie vielleicht einen Blick auf, wie Samba erleichtert debugging; es hat einen konfigurierbaren "Panik-Aktion" kann Aussetzung der Anwendung, Benachrichtigen Sie den Entwickler, spawn gdb, usw., und wird als Teil der signal-handler. Sehen lib/util/Fehler.c in den Samba-source-tree.

    InformationsquelleAutor Josh Kelley
Schreibe einen Kommentar