Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: .NET Core 2.1, .NET Core 3.1, .NET 5
In diesem Artikel wird erläutert, wie Sie den lldb-Debugger in Linux installieren und konfigurieren und dann vom System generierte .NET Core-Dumpdateien öffnen und analysieren.
Voraussetzungen
Die Mindestanforderung, diese Problembehandlungslabore zu befolgen, besteht darin, eine ASP.NET Core-Anwendung zu haben, um Probleme mit niedriger CPU- und hoher CPU-Leistung zu veranschaulichen.
Sie finden mehrere Beispielanwendungen, um dieses Ziel im Internet zu erreichen. Sie können beispielsweise das einfache Webapi-Beispiel von Microsoft herunterladen und einrichten, um unerwünschtes Verhalten zu veranschaulichen. Oder Sie können BuggyAmb ASP.NET Core-Anwendung als Beispielprojekt verwenden.
Wenn Sie die vorherigen Teile dieser Reihe befolgt haben, sollten Sie die folgende Einrichtung ausführen:
- Nginx ist so konfiguriert, dass zwei Websites gehostet werden:
- Die ersten Lauschen auf Anforderungen mithilfe des Myfirstwebsite-Hostheaders (
http://myfirstwebsite) und des Routings von Anforderungen an die Demo-ASP.NET Core-Anwendung, die auf Port 5000 lauscht. - Die zweite lauscht auf Anforderungen mithilfe des Cartamb-Hostheaders (
http://buggyamb) und des Routings von Anforderungen an die zweite ASP.NET Core-Beispiel-Buggy-Anwendung, die auf Port 5001 lauscht.
- Die ersten Lauschen auf Anforderungen mithilfe des Myfirstwebsite-Hostheaders (
- Beide ASP.NET Core-Anwendungen sollten als Dienste ausgeführt werden, die automatisch neu gestartet werden, wenn der Server neu gestartet wird oder die Anwendung nicht mehr reagiert.
- Die lokale Linux-Firewall ist aktiviert und konfiguriert, um SSH- und HTTP-Datenverkehr zuzulassen.
Notiz
Wenn Ihr Setup nicht bereit ist, wechseln Sie zu "Teil 2 Erstellen und Ausführen ASP.NET Core-Apps".
Um dieses Lab fortzusetzen, müssen Sie mindestens eine problematische ASP.NET Core-Webanwendung haben, die hinter Nginx ausgeführt wird.
Ziel dieses Labors
Dieser Artikel ist der zweite von zwei Lab-Komponenten zum Debuggen von Abstürzen von ASP.NET Core-Anwendungen unter Linux.
In Lab 1.1 Reproduzieren und Beheben eines Absturzproblems haben Sie die Schritte zum Reproduzieren eines Absturzproblems befolgt und mit der Problembehandlung begonnen. Sie haben Nginx und die Systemprotokolle überprüft und die Problembehandlung fortgesetzt, indem Sie eine Speicherabbilddatei erfassen und analysieren. Sie haben die Absturzkernabbilddatei extrahiert, die von apport generiert wurde, dem Core Dump File Manager von Ubuntu.
In diesem Teil installieren und konfigurieren Sie den lldb-Debugger für die Zusammenarbeit mit der Erweiterung .NET Core debugger that's named SOS, und öffnen Sie dann die Dumpdatei in lldb, um sie zu analysieren.
Lldb installieren
Für diese Übung müssen Sie lldb 3.9 oder eine höhere Version installieren. Anweisungen für mehrere Linux-Distros sind in der Installation von LLDB unter Linux detailliert beschrieben. Für diesen Abschnitt empfehlen wir die Verwendung des apt Installationsbefehls: sudo apt install lldb. Im folgenden Screenshot können Sie sehen, dass die lldb-6.0 zusammen mit einigen Abhängigkeiten installiert ist.
Nach Abschluss der Installation müssen Sie lldb so konfigurieren, dass sie SOS automatisch laden kann, wenn eine Kernabbilddatei geöffnet wird.
Konfigurieren von lldb
Bevor Sie die Kernabbilddatei in lldb öffnen, führen Sie die folgenden erforderlichen Schritte aus, um den Symbolpfad festzulegen, die Symbole herunterzuladen und das SOS automatisch zu laden, wenn lldb geöffnet wird:
Installieren Sie das Dotnet-Symbol-Tool:
dotnet tool install -g dotnet-symbolLaden Sie die Symbole für die Zielabbilddatei herunter:
dotnet-symbol <path_of_dump_file>Installieren Sie SOS:
Installieren Sie das globale Tool dotnet-sos:
dotnet tool install -g dotnet-sosInstallieren Sie SOS:
dotnet-sos install
Installieren des Dotnet-Symbol-Tools
Sie sollten das Dotnet-Symbol-Tool bereits zusammen mit dotnet-dump- und dotnet-gcdump-Tools im vorherigen Teil installiert haben. Wenn Sie diese Tools noch nicht installiert haben, installieren Sie sie, bevor Sie fortfahren. Führen Sie dazu den dotnet tool install -g dotnet-symbol Befehl aus, um dotnet-symbole zu installieren. Installieren Sie dotnet-dump und dotnet-gcdump, wenn Sie dies noch nicht getan haben. Sie sollten nun drei Tools installiert haben, wie im folgenden Screenshot gezeigt.
Herunterladen von Symbolen für die Dumpdatei
In Teil 1 wurden Sie angewiesen, die Entpackung der Kernabbilddatei aus dem Apport-Bericht zu entpacken. Jetzt ist es an der Zeit, die Symboldateien herunterzuladen. Wie in diesem Artikel erläutert, funktionieren Symbole auf hoher Ebene. Sie dienen als Zuordnungen zwischen dem Quellcode und den Binärdateien. Diese Zuordnungen werden von Debuggern verwendet, um die Funktions- oder Methodennamen, Quellzeileninformationen oder lokalen Variablennamen aufzulösen, wenn sie einen Aufrufstapel lesen.
Sie verwenden den dotnet-symbol ~/dumps/dotnet/CoreDump -o ~/dumps/symbols --host-only Befehl, um die Symbole für die Speicherabbilddatei in das ~/dumps/symbols Verzeichnis herunterzuladen.
Möglicherweise werden beim Herunterladen von Symboldateien mehrere Fehlermeldungen "HTTP 404 nicht gefunden" angezeigt, wenn Sie den --host-only Schalter nicht hinzufügen. Diese Meldungen können gefahrlos ignoriert werden. Der --host-only Parameter lädt nur das Hostprogramm herunter. Dies alles, was lldb benötigt, um das Debuggen der ASP.NET Core-Anwendung zu starten.
Der nächste Schritt besteht darin, die SOS-verwaltete Debugerweiterung zu installieren. Dadurch werden die .NET-Debuggingbefehle verfügbar gemacht, die zum Ausführen der Analyse erforderlich sind.
Installieren von SOS
Was ist SOS? Laut der offiziellen Dokumentation ist SOS eine Debuggererweiterung, die es einem Entwickler ermöglicht, den verwalteten Zustand einer .NET-Anwendung zu prüfen, einschließlich des ASP.NET Core und anderer. NET-basierte Anwendungen wie .NET WPF und .NET Windows Forms. SOS ist eine plattformübergreifende Erweiterung, die von WinDbg oder einem CDB-Debugger unter Windows und von lldb unter Linux und macOS geladen werden kann.
Um SOS zu installieren, müssen Sie zuerst das folgende dotnet-sos-Tool installieren:
dotnet tool install -g dotnet-sos
Installieren Sie dann SOS:
dotnet-sos install
Der folgende Screenshot zeigt das Ergebnis einer erfolgreichen Installation. Beachten Sie, dass das dotnet-sos-Tool den lldb-Debugger so konfiguriert hat, dass die SOS-Erweiterung automatisch geladen werden soll, wenn der Debugger gestartet wird.
Sie sind schließlich bereit, die Dumpdatei mithilfe von lldb zu öffnen.
Öffnen des Kernabbilds in lldb
Um das Kernabbild zu öffnen, müssen Sie lldb und die folgende Syntax verwenden:
lldb --core <dump path> <host-program>
Dies <host-program> ist das systemeigene Programm, das die .NET Core-Anwendung gestartet hat. Dies ist in der Regel dotnet, es sei denn, die Anwendung ist eigenständig. Wenn es sich um eine eigenständige Anwendung handelt, ist diese Variable der Name der Anwendung ohne die .dll Erweiterung.
Wenn Sie die gleichen Ordnernamen verwenden, sollte der Pfad zur Speicherabbilddatei, die Sie im vorherigen Abschnitt generiert haben, ~/dumps/dotnet/CoreDump lauten. Daher werden Sie ausgeführt lldb --core ~/dumps/dotnet/CoreDump , um die Datei zu öffnen.
Der folgende Screenshot zeigt den lldb-Debugger, der die Speicherabbilddatei geöffnet hat.
Festlegen von Symbolen
Erinnern Sie sich daran, dass Sie die Symboldateien mithilfe des dotnet-symbol Befehls im ~/dumps/symbols Verzeichnis heruntergeladen haben. Der erste Befehl, den Sie im Debugger ausführen sollten, besteht darin, den Symbolserverpfad auf das Verzeichnis festzulegen, das Sie für die Symboldownloads festgelegt haben:
setsymbolserver -directory ~/dumps/symbols
Laden Sie als Nächstes die Symbole: loadsymbols
Ausführen von LLDB- und SOS-Befehlen
Es gibt mehrere Lldb-Befehle. Sie können diese mithilfe des help Befehls auflisten. In der Liste können Sie sehen, dass die SOS-Befehle auch unter benutzerdefinierten Befehlen aufgeführt sind. SOS ist ein Plug-In für lldb. Mithilfe desselben help Befehls können Sie Plug-In-Hilfeinformationen abrufen.
Notiz
Möglicherweise möchten Sie die LLDB-Ausgabe gelegentlich löschen. Drücken Sie dazu STRG+L.
Sehen Sie sich zunächst den systemeigenen Aufrufstapel des Threads mithilfe des bt Befehls "Zurückverfolgung" an. Dieser Befehl zeigt den Aufrufstapel des aktiven Threads an.
Überprüfen Sie als Nächstes den verwalteten Aufrufstapel mithilfe des SOS-Befehls clrstack .
Sie sollten keine Informationen abrufen können. Der Stapel-Walk schlägt fehl, da der gemeldete Stapel unvollständig ist. Dies bezieht sich auf das, was zuvor erläutert wurde: Die automatisch generierte Kernabbilddatei kann nicht alle verwalteten Zustände erfassen.
Erinnern Sie sich auch daran, dass eine Ausnahme aufgetreten ist und dies dazu führte, dass der Vorgang abstürzte. Sehen Sie sich die Ausnahmeinformationen an, indem Sie den SOS-Befehl pe ausführen.
Wie Sie in der Ausgabe sehen können, zeigt der pe Befehl ggf. die Informationen zur letzten Ausnahme an, die im aktuellen Thread ausgelöst wurde.
Die Ausnahmemeldung in diesem Fall ist die Ressource vorübergehend nicht verfügbar. Der Ausnahmetyp und die Funktionsnamen werden jedoch nicht aufgelöst. Stattdessen werden ihre Werte als unbekannt angegeben.
Die Adresse der Ausnahme wird ebenfalls angezeigt. Sie können versuchen, diese Adresse als Parameter im pe Befehl zu übergeben, um festzustellen, ob weitere Details verfügbar sind. Führen Sie dann pe 00007F8244048538 aus.
Notiz
Ersetzen Sie in diesem Befehl die Adresse durch die Adresse, die in der Speicherabbilddatei angezeigt wird.
Auch wenn Sie die Objekte anzeigen möchten, auf die im Stapel verwiesen wird, wird derselbe Wert unbekannt angezeigt.
Sie können versuchen, weitere Informationen abzurufen, indem Sie eine Adresse eines der Objekte im Stapel auswählen und das Objekt mithilfe des dumpobj <address> Befehls überprüfen.
Sie werden jedoch wahrscheinlich schließen, dass dieser Befehl auch eingeschränkt wirkt, da er nur unbekannte Nachrichten zurückgibt. Es ist an der Zeit, die Arbeit mit der automatisch generierten Dumpdatei zu beenden. Führen Sie den exit Befehl aus, um die lldb-Sitzung zu beenden.
Zusammenfassend gibt ihnen die vom System generierte Dumpdatei einige Informationen, aber Sie fehlen immer noch einige wichtige Informationen. Im nächsten Teil werden Sie den empfohlenen Ansatz zum Erfassen eines Absturzabbilds vorgestellt.