Übung 1.2 Problembehandlung bei Abstürzen – Analysieren von vom System generierten Kernabbilddateien in lldb-Debugger
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-Abbilddateien öffnen und analysieren.
Voraussetzungen
Die Mindestanforderung für die Durchführung dieser Problembehandlungslabore besteht darin, über eine ASP.NET Core Anwendung zu verfügen, um Leistungsprobleme mit geringer CPU- und hoher CPU-Leistung zu demonstrieren.
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 demonstrieren. Alternativ können Sie auch ASP.NET Core Anwendung als Beispielprojekt verwenden.
Wenn Sie die vorherigen Teile dieser Reihe befolgt haben, sollten Sie das folgende Setup bereit haben:
- Nginx ist so konfiguriert, dass zwei Websites gehostet werden:
- Der erste lauscht auf Anforderungen mithilfe des Hostheaders "myfirstwebsite" (
http://myfirstwebsite) und Routinganforderungen an die Demo ASP.NET Core Anwendung, die auf Port 5000 lauscht. - Der zweite lauscht auf Anforderungen mithilfe des hostsamb-Hostheaders (
http://buggyamb) und Routinganforderungen an die zweite ASP.NET Core Beispielanwendung, die auf Port 5001 lauscht.
- Der erste lauscht auf Anforderungen mithilfe des Hostheaders "myfirstwebsite" (
- 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 so konfiguriert, dass SSH- und HTTP-Datenverkehr zulässig ist.
Hinweis
Wenn Ihr Setup noch nicht bereit ist, wechseln Sie zu"Teil 2 Erstellen und Ausführen ASP.NET Core Apps".
Um diese Übung fortzusetzen, benötigen Sie mindestens eine problematische ASP.NET Core Webanwendung, die hinter Nginx ausgeführt wird.
Ziel dieser Übung
Dieser Artikel ist der zweite von zwei Übungsteilen zum Debuggen von Abstürzen von ASP.NET Core-Anwendungen unter Linux.
In Übung 1.1reproduzieren und beheben Sie ein Absturzproblem. Sie haben 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 gesammelt und analysiert haben. Sie haben die Absturzkernabbilddatei extrahiert, die von apport, Ubuntus Zentralem Speicherabbilddatei-Manager, generiert wurde.
In diesem Teil installieren und konfigurieren Sie den lldb-Debugger für die Zusammenarbeit mit der .NET Core-Debuggererweiterung namens SOS, und öffnen dann die Speicherabbilddatei in lldb, um sie zu analysieren.
Installieren von lldb
Für diese Übung müssen Sie lldb 3.9 oder eine höhere Version installieren. Anweisungen für mehrere Linux-Distributionen finden Sie in der Installation von LLDB unter Linux. In diesem Abschnitt wird empfohlen, den Installationsbefehl zu apt verwenden: sudo apt install lldb . Im folgenden Screenshot sehen Sie, dass die lldb-6.0 zusammen mit einigen Abhängigkeiten installiert ist.
Nach Abschluss der Installation müssen Sie lldb so konfigurieren, dass so automatisch SOS geladen werden kann, wenn eine Kernabbilddatei geöffnet wird.
Konfigurieren von lldb
Bevor Sie die Kernabbilddatei in lldb öffnen, führen Sie die folgenden Schritte aus, um den Symbolpfad festzulegen, die Symbole herunterzuladen und den SOS automatisch zu laden, wenn lldb geöffnet wird:
Installieren Sie das Dotnet-Symboltool:
dotnet tool install -g dotnet-symbolLaden Sie die Symbole für die Zielabbilddatei herunter:
dotnet-symbol <path_of_dump_file>Sos installieren:
Installieren Sie das globale Tool dotnet-sos:
dotnet tool install -g dotnet-sosSos installieren:
dotnet-sos install
Installieren des Dotnet-Symboltools
Sie sollten das Dotnetsymboltool 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 Dotnetsymbole zu installieren. Installieren Sie dotnet-dump und dotnet-gcdump, wenn Sie dies noch nicht getan haben. Sie sollten jetzt drei Tools installiert haben, wie im folgenden Screenshot dargestellt.
Downloadsymbole für die Speicherabbilddatei
In Teil 1wurden Sie angewiesen, die Kernabbilddatei aus dem Apport-Bericht zu entpacken. Jetzt ist es an der Zeit, die Symboldateien herunterzuladen. Wie in diesem Artikelerlä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 erhalten Sie beim Herunterladen von Symboldateien mehrere Fehlermeldungen vom Typ "HTTP 404 nicht gefunden", wenn Sie den Switch nicht --host-only hinzufügen. Sie können diese Nachrichten ignorieren. Der --host-only Parameter lädt nur das Hostprogramm herunter. Dies ist alles, was lldb benötigt, um mit dem Debuggen der ASP.NET Core Anwendung zu beginnen.
Der nächste Schritt besteht darin, die SOS-verwaltete Debugerweiterung zu installieren. Dadurch werden die .NET-Debugbefehle verfügbar gemacht, die zum Ausführen der Analyse erforderlich sind.
SoS installieren
Was ist SOS? Gemäß der offiziellen Dokumentationist SOS eine Debuggererweiterung, mit der ein Entwickler den verwalteten Status einer .NET-Anwendung überprüfen kann, einschließlich der 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 auf 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 Tool dotnet-sos den Lldb-Debugger so konfiguriert hat, dass die SOS-Erweiterung automatisch geladen werden soll, wenn der Debugger gestartet wird.
Sie können die Speicherabbilddatei schließlich mithilfe von lldb ö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>
Das <host-program> 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 erweiterung.dll.
Wenn Sie mit denselben Ordnernamen folgen, sollte der Pfad zur Speicherabbilddatei, die Sie im vorherigen Abschnitt generiert haben, ~/dumps/dotnet/CoreDump sein. Daher führen Sie die Ausführung aus, 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
Denken Sie daran, dass Sie die Symboldateien mithilfe des Befehls im Verzeichnis heruntergeladen dotnet-symbol ~/dumps/symbols haben. Der erste Befehl, den Sie innerhalb des Debuggers ausführen sollten, besteht darin, den Pfad des Symbolservers 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. Mit demselben Befehl können Sie Informationen zur Plug-In-Hilfe help abrufen.
Hinweis
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ück-Ablaufverfolgung" an. Dieser Befehl zeigt den Aufrufstapel des aktiven Threads an.
Untersuchen Sie als Nächstes den verwalteten Aufrufstapel mithilfe des clrstack SOS-Befehls.
Sie sollten keine Informationen abrufen können. Der Stapelspaziergang schlägt fehl, da der gemeldete Stapel unvollständig ist. Dies bezieht sich auf das, was zuvor besprochen wurde: Die automatisch generierte Kernabbilddatei kann nicht alle verwalteten Zustände erfassen.
Denken Sie auch daran, dass eine Ausnahme aufgetreten ist und der Prozess 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 die Informationen zur letzten Ausnahme an, sofern vorhanden, die im aktuellen Thread ausgelöst wurde.
Die Ausnahmemeldung ist in diesem Fall 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 Befehl zu pe übergeben, um festzustellen, ob weitere Details verfügbar sind. Führen Sie dann pe 00007F8244048538 .
Hinweis
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 davon ausgehen, dass dieser Befehl auch eine begrenzte Auswirkung hat, da er nur unbekannteere Nachrichten zurückgibt. Es ist an der Zeit, die Arbeit mit der automatisch generierten Speicherabbilddatei zu beenden. Führen Sie den exit Befehl aus, um die lldb-Sitzung zu beenden.
Zusammenfassend lässt sich zusammenfassen, dass die vom System generierte Speicherabbilddatei Ihnen einige Informationen liefert, aber Es fehlen noch einige wichtige Informationen. Im nächsten Teil wird Ihnen der empfohlene Ansatz zum Erfassen eines Absturzabbilds vorgestellt.