Mein aktuelles Problem ist libwebkitgtk-3.0-0, aber ich denke, dieses Problem ist generisch genug.
Meine Anwendung stürzt irgendwo im Webkit-Code ab. Meine Annahme ist, dass wir etwas Dummes tun und herausfinden wollen, was. Am einfachsten ist es, einen Haltepunkt zu setzen oder die Debug-Version der Bibliothek zu verwenden.
Wie bekomme ich genauen Quellcode mit welcher Bibliothek gebaut wurde? Ich bekomme Stack-Trace, nachdem es den Kern ablegt, aber die Zeilennummer, die gdb sagt, stimmt nicht mit denen überein, die ich im Code sehe. Mit anderen Worten, wenn ich libwebkitgtk-3.0-0 installiere, möchte ich den genauen Quellcode davon bekommen.
Ich habe die Debug-Version der Webkit-Bibliothek installiert. Haben diese Debug-Versionen die gleiche Funktionalität, als würden Sie Webkit mit --enable-debug flag kompilieren? Debug-Versionen von Webkit ermöglichen die Protokollierung basierend auf der Umgebungsvariablen WEBKIT_DEBUG, aber ich konnte nicht die gleiche Protokollierung erhalten, selbst wenn ich die Debug-Version der Bibliothek verwende.
Wie verwende ich die Debug-Version, die ich kompilieren konnte? Ich habe es geschafft, Webkit auf meinem Rechner zu kompilieren und habe versucht, mit Lastpfaden und so zu spielen. Meine Anwendung übernimmt keine neue gemeinsame Bibliothek, egal was ich mache - ich kann anhand der Signatur des Benutzeragenten sagen. Irgendwann schaffte ich es, die Bibliothek zu holen, aber dann funktioniert SSL nicht mehr. Das gleiche SSL-Problem tritt bei GtkLauncher auf. Also mache ich irgendwo Fehler.
Danke für die Hinweise.
1) Wenn ich eine Bibliothek durchsuchen muss, die ich über ein Paket installiert habe, installiere ich sie als erstes aus der Quelle. Ich meine configur / make / make install. Normalerweise stelle ich den Quellcode in / usr / local / src und installiere ihn in / usr / local. Dies ist meiner Meinung nach die zuverlässigste Art, den genauen Code auszuführen, für den Sie die Quelle haben.
3)
Wie verwende ich die Debug-Version, die ich kompilieren konnte?
Das hört sich so an, als hätten Sie getan, was ich oben beschrieben habe. Was Sie tun müssen, ist sicherzustellen, dass Ihre Software die Include- und Link-Verzeichnisse verwendet, die Ihre kompilierte, debuggeschaltete Bibliothek hosten. Das bedeutet, dass die Flags -I / usr / local / include und -L / usr / local / lib gesetzt sind und sie vor / usr / include und / usr / lib stehen.
Sie können noch sicherer sein, indem Sie die Binärversion der Bibliotheken aus der Ubuntu-Installation entfernen und sicherstellen, dass die Version, die Sie erstellt und installiert haben, die einzige Version auf der Festplatte ist. Auf diese Weise können Sie sicher sein, dass Sie Ihre App für die Verwendung dieser Bibliothek konfigurieren konnten. Sonst wird es einfach scheitern, anstatt sich ständig zu fragen, ob es die neue Bibliothek oder die alte Bibliothek benutzt.
2) Normalerweise ja. Aber es hängt davon ab, wie die Bibliothek geschrieben ist und was der Ubuntu-Packer getan hat.
Wenn Sie das Programm mit Ihrer lokal erstellten Bibliothek kompiliert haben, sehen Sie, ob Sie genau den gleichen Fehler erhalten. Wenn nicht, dann ist das auch ein Datenpunkt. Vielleicht wurde das Problem behoben, seit ubuntu das letzte Mal die Bibliothek gepackt hat. Vielleicht ist die Bibliothek nicht richtig verpackt und das ist das Problem. Sie könnten sogar neue Fehler bekommen, weil der Ubuntu-Packer die Bibliothek auf eine bestimmte Art und Weise konfiguriert hat, so dass es funktioniert und Sie nicht dasselbe getan haben. Du wirst trotzdem interessante Hinweise bekommen.
Viel Glück
TL; DR: Installieren Sie libwebkitgtk-3.0-0-dbg Installieren Sie libwebkitgtk-3.0-0-dbg http://hostmar.co/software-small , dann haben Sie die notwendigen Debug-Symbole.
Wie Sie wissen, können Sie GCC mit -g ausführen, um Debug-Symbole für Software zu erhalten, die Sie selbst erstellen.
Für Software, die über den Paketmanager Ihres Betriebssystems installiert wird (der libwebkitgtk-3.0-0 enthält), gibt es, zumindest für offizielle Pakete, normalerweise auch Pakete, die Debug-Symbole bereitstellen .
Sie müssen nicht unbedingt einen Debug-Build eines Programms oder einer Bibliothek erstellen, um eine symbolische Stack-Ablaufverfolgung in gdb zu erhalten. gdb unterstützt auch Dateien, die "Add-On" Debug-Symbole in /usr/lib/debug bereitstellen.
Sie verwenden Ubuntu entsprechend den Tags Ihrer Frage. Unter Ubuntu sind Debug-Symbolpakete in zwei Varianten verfügbar: -dbg und -dbgsym . Ein Programm oder eine Bibliothek, die sich in /path befindet, erhält Debug-Symbole bei /usr/lib/debug/path .
-dbg Pakete Diese Pakete werden oft anders benannt als die entsprechenden Pakete, die die eigentlichen ausführbaren Dateien oder Bibliotheksdateien enthalten. Sie werden oft ähnlich wie -dev packages (die Header-Dateien bereitstellen) und -doc packages benannt. Ein -dbg -Paket weist im Namen manchmal eine geringere Nummerierung der Bibliotheksversion als die eigentlichen Bibliothekspakete auf und deckt manchmal Binärdateien ab, die in mehreren anderen Paketen enthalten sind.
Zum Beispiel ist libgtkmm-3.0-1 das entsprechende -dbg -Paket libgtkmm-3.0-dbg .
Andererseits wird manchmal ein Paket -dbg genauso benannt wie das Paket, dessen Symbole es enthält (mit Ausnahme des Suffix -dbg ). Zum Beispiel ist libwebkitgtk-3.0-0 das entsprechende -dbg -Paket libwebkitgtk-3.0-0-dbg . Das ist das, was Sie wollen.
Sie können es im Software Center installieren oder indem Sie Folgendes ausführen:
%Vor% Wenn Sie nun ein Programm debuggen, das auf eine von libwebkitgtk-3.0-0 bereitgestellte Bibliothek verweist, lädt gdb automatisch Symbole aus einer Datei, die von libwebkitgtk-3.0-0-dbg bereitgestellt wird.
-dbgsym Pakete Manchmal enthalten binäre ausführbare Dateien, die von einem offiziellen Paket bereitgestellt werden, keine Symbole, die in einem -dbg -Paket enthalten sind. In diesem Fall können Sie normalerweise das Paket -dbgsym installieren.
Im Gegensatz zu -dbg packages, -dbgsym packages:
X-dbgsym wobei X das Paket ist, das das Programm oder die Bibliothek selbst bereitstellt. -dbg packages bereitgestellt. Da sich -dbgsym -Pakete in separaten Repositories befinden, müssen Sie diese Repositories aktivieren. Ihre DEB-Zeilen sind:
Um sie zu aktivieren, können Sie diese Befehle ausführen (angepasst von DebuggingProgramCrash von "Weiterverteiler zum Ubuntu-Dokumentations-Wiki , Abschnitt 2 ):
%Vor%
Lassen Sie die Zeilen kursiv weg, wenn Sie sich in einer Entwicklungsversion (Alpha oder Beta) befinden. Stellen Sie sicher, dass Sie sie hinzufügen, wenn Sie das Release weiterhin stabil verwenden.
Diese Befehle machen drei Dinge:
/etc/apt/sources.list.d/ddebs.list (die die DEB-Zeilen enthält). Wenn Sie also die -dbgsym -providierten Symbole anstelle der -dbg bereitgestellten Symbole verwenden möchten, ist das -dbgsym -Paket für libwebkitgtk-3.0-0 (in Übereinstimmung mit der obigen einfachen Namenskonvention) libwebkitgtk-3.0-0-dbgsym .
Sie können sowohl -dbg als auch -dbgsym Pakete auf demselben System installiert haben, aber nicht, wenn sie Symbole für die gleichen Dateien bereitstellen . Also kollidieren libwebkitgtk-3.0-0-dbg und libwebkitgtk-3.0-0-dbgsym miteinander; Sie können nicht beide (gleichzeitig) installiert werden.
Auf den meisten Unix-ähnlichen Betriebssystemen sucht der Debugger automatisch nach installierten Symbolen. Ubuntu ist nicht anders - in Ubuntu sucht gdb automatisch nach ihnen in /usr/lib/debug . Sie müssen also nichts Besonderes tun.
Wenn Sie jedoch gdb mitteilen müssen, dass eine bestimmte Debugsymbol-Datei geladen werden soll, verwenden Sie das Flag -s file . Siehe das GNU-Handbuch und gdb (1) für Details.
@ Eliahs Antwort sagt, wie man Symbole auf bequeme Weise erhält.
Die Frage bleibt, "Wie bekomme ich den genauen Quellcode?" .
Normalerweise mache ich apt-get source <pkgname> , was gut und gut ist, außer dann muss ich gdb dir <path-to-wherever-I-put-the-source> manuell sagen und wehe, wenn es ein Paket wie eglibc ist, wo man herausfinden muss, dass der Pfad verweist stammen aus dem Unterverzeichnis nss , nicht aus dem Stammverzeichnis.
Auf RHEL tut man einfach z.B. yum install --enable-repo rhel-debuginfo libX11-debuginfo (nur yum install libX11-debuginfo auf CentOS 7) und sofort erhalten Sie die vollständigen Symbole und die Quelle in gdb ohne extra herumzualbern. Ich suche immer noch nach dieser Bequemlichkeit auf Ubuntu.