Debug core-Datei, die ohne Symbole

Ich habe eine C-Anwendung, die wir bereitgestellt haben, um die Kunden vor Ort. Es wurde kompiliert und läuft auf HP-UX. Der Benutzer hat berichtet, crash-und wir haben gewonnen ein core dump. So weit, ich habe nicht in der Lage zu duplizieren die crash im Haus.

Als würden Sie Ahnen, den die core-Datei/bereitgestellte ausführbare ist völlig frei von jeglicher Art von Symbolen. Wenn ich laden Sie es in gdb, und machen Sie einen bt, die beste, die ich bekomme, ist diese:

(gdb) bt
#0  0xc0199470 in ?? ()

Ich tun kann, "strings core" auf die Datei, aber mein Verständnis ist, dass alles, was ich bekommen es ist alle strings in der ausführbaren Datei, so scheint es, semi-unmöglich, auf die Spur von allem was dabei.

Habe ich eine debug-version (kompiliert mit -g) der EXE-Datei, die ist leider ein paar Monate neuer als die version freigegeben. Wenn ich versuche, starten Sie gdb mit diesem hub, ich sehe dies:

warning: exec file is newer than core file.
Core was generated by `program_name'.
Program terminated with signal 11, Segmentation fault.
__dld_list is not valid according to __dld_flags.

#0  0xc0199470 in ?? ()
(gdb) bt
#0  0xc0199470 in ?? ()

Zwar wäre es möglich eine debug-version kompilieren und installieren Sie es auf der Kunden-Website, und warten Sie dann für ein weiteres crash, wäre es relativ schwierig und nicht wünschenswert für eine Reihe von Gründen.

Ich bin sehr vertraut mit dem code, und haben eine relativ gute Vorstellung davon, wo im code es abstürzt, ausgehend von den Kunden-Fehlerbericht.

Gibt es eine Möglichkeit, dass ich Lesen können, keine weiteren Informationen von dieser core-dump? Über strings oder einem anderen debugger oder so was? Danke.

InformationsquelleAutor der Frage Morinar | 2009-06-26

  1. 9

    Diese Art der Antwort von gdb:

    (gdb) bt
#0  0xc0199470 in ?? ()

    kann auch geschehen in dem Fall, dass der Stapel wurde zerstört durch einen buffer overrun, wo die Rücksprungadresse überschrieben wurde, im Speicher, so dass der Programm counter wird gesetzt zu einem scheinbar zufälligen Bereich.

    Dies ist eine der Möglichkeiten, dass selbst eine bauen, mit einem entsprechenden symbol-Datenbank kann zu einem symbol lookup error (oder seltsam aussehende Ablaufverfolgungen). Wenn Sie immer noch dieses, nachdem Sie die symbol-Tabelle, Ihr problem ist wahrscheinlich, dass die Daten Ihrer Kunden verursachen einige Probleme mit Ihrem code.

    InformationsquelleAutor der Antwort Sufian

  2. 6

    Für die Zukunft:

    1. Stellen Sie sicher, dass bauen immer mit einem externen Symbole-Datenbank (dies ist nicht ein debug-build-es ist ein release bauen, aber Sie speichern die symbol-Tabelle separat)
    2. halten Sie es für die Versionen, die Sie bereitstellen

    Für diese situation:

    Wissen Sie, den Allgemeinen Bereich, so um zu sehen, ob Sie richtig sind, gehen Sie auf die stack-trace und finden Sie den Assembler code -- Augapfel und sehen, wenn Sie denken, dass Sie mit Ihrer Quelle (dies ist einfacher, wenn Sie eine Idee haben, was Quelle erzeugte assembly). Wenn es richtig aussieht, dann haben Sie einige Verifizierung Ihrer Hypothese. Sie könnten in der Lage sein, um herauszufinden, die Werte der lokalen Variablen, indem man die Stapel (da Sie wissen, was Sie übergeben, und erklärt).

    InformationsquelleAutor der Antwort Lou Franco

  3. 3

    Unter gdb, "info Register" sollte genügen, die Hinrichtung Zustand zum Zeitpunkt des Absturzes in Verwendung mit einer Demontage der ausführbaren Datei und entsprechenden shared libraries. Ich in der Regel mit objdump zum disassemblieren, Ausgabe in eine Datei umleiten, schalten Sie dann die Datei in meinem Lieblings-editor - dies ist nützlich für das halten Notizen, wie die Dinge sind klar. Auch der gdb ist "info " target" und "info sharedlib" kann nützlich sein, um herauszufinden, wo die gemeinsamen Bibliotheken geladen werden.

    Mit register Zustand, stack-Inhalt und die Demontage in der hand zusammen mit ein wenig Glück, sollte es Recht einfach sein (wenn mühsam) rekonstruieren, die callstack (es sei denn, natürlich, der stack wurde verwüstet durch einen Pufferüberlauf oder eine ähnliche Katastrophe... vielleicht brauchen ein Ouija-Brett oder crystal ball in diesem Fall.)

    Könnten Sie auch in der Lage sein, korreliert eine Demontage der neueren version mit -g gegen die Demontage der stripped version.

    InformationsquelleAutor der Antwort Lance Richardson

  4. 2
    1. Immer mit einer Versionsverwaltung (CVS/GIT/Subversion/etc), auch für test-Versionen
    2. Tag alle releases
    3. Betrachten (in der Zukunft) bauen, die mit debugging (-g) und Streifen Sie die ausführbare Datei vor dem Versand. HINWEIS: machen Sie nicht zwei builds mit und ohne -g; Sie können auch nicht übereinstimmen, da -g kann gelegentlich dazu führen, dass verschiedene code generiert werden, selbst bei gleicher Optimierungsstufe. Im super-performance-kritischen code kann man verzichten -g für kritische Dateien - die meisten ist es nicht einen Unterschied machen.
    4. Wenn Sie wirklich stecken, dump stack und dump relevanten Teile des Haufens zu hex und schauen Sie es von hand; vielleicht unter einer instrumentierten kopieren und auf der Suche nach ähnlichen "Signaturen" in den generierten code und auf dem stack. Dies ist real "old-school" Debuggen... 🙂

    InformationsquelleAutor der Antwort jesup

  5. 1

    Haben Sie die genaue Quelle, die Sie verwendet, um zu kompilieren die alte version (eg; durch einen tag in den source-tree oder so ähnlich)? Vielleicht könnten Sie neu erstellen mit, und vielleicht bekommen einen Einblick, wo der Absturz aufgetreten?

    InformationsquelleAutor der Antwort EightyEight

  6. 1

    Versuchen, eine "pmap" gegen die core-Datei (wenn hp/ux hat dieses tool). Dieser Bericht sollte die Start-Adressen für alle Module der core-Datei. Mit dieser info, Sie sollten in der Lage sein zu nehmen, die Adresse des Fehlerort-und herauszufinden, was die Bibliothek stürzte. Weitere Adresse-Vergleich zwischen dem crash-Adresse und die Adressen der bekannten Funktionen in der Bibliothek ("nm" gegen die Bibliothek sollte erhalten) kann Ihnen helfen, festzustellen, welche Funktion abgestürzt.

    Selbst wenn es Ihnen gelingt zu identifizieren, die die Funktion oben auf dem stack, es ist nicht sehr wahrscheinlich, dass diese Funktion die Quelle des Problems... hoffentlich hat es tatsächlich stürzte in Ihrem code und nicht, sagen wir, die standard C string-Bibliothek. Wiederaufbau der stack-trace ist die nächste beste Sache an diesem Punkt.

    InformationsquelleAutor der Antwort veefu

  7. 0

    Gibt es nicht viel Informationen hier. Die binäre abgestreift.Aber ein Blick auf "segmentation fault" ...sollten Sie sich für Orte, wo die Möglichkeit besteht, dass Sie überschreiben einen Teil des Speichers.

    Dies ist nur ein Vorschlag. Es kann viele Probleme.

    BTW, wenn Sie nicht in der Lage zu reproduzieren, die in Ihrer lokalen Maschine dann das Volumen von Daten über die Kunden könnte ein problem sein.

    InformationsquelleAutor der Antwort Vaibhav

  8. 0

    Ich glaube nicht, dass die core-Datei enthalten soll, Symbole. Sie müssen in der Lage, erstellen Sie eine version des Programms, die genau das gleiche als das, was Sie geliefert, um Ihre Kunden, aber mit -g. Wenn Sie strip-debug-ausführbare Datei, es sollte identisch sein mit der gelieferten version. Nur dann kann der gdb geben Sie etwas nützliches.

    InformationsquelleAutor der Antwort sigjuice

Schreibe einen Kommentar