Lab 1.2 Risoluzione dei problemi relativi ad arresti anomali- Analizzare i file di dump di base generati dal sistema nel debugger lldb

Si applica a: .NET Core 2.1, .NET Core 3.1, .NET 5

Questo articolo illustra come installare e configurare il debugger lldb in Linux e quindi aprire e analizzare i file di dump di .NET Core generati dal sistema.

Prerequisiti

Il requisito minimo per seguire questi lab per la risoluzione dei problemi consiste nell'avere un'applicazione ASP.NET Core per illustrare problemi di prestazioni a cpu bassa e CPU elevata.

È possibile trovare diverse applicazioni di esempio per raggiungere questo obiettivo su Internet. Ad esempio, è possibile scaricare e configurare l'esempio webapi semplice di Microsoft per illustrare il comportamento indesiderato. In alternativa, è possibile usare BuggyAmb ASP.NET'applicazione Core come progetto di esempio.

Se sono state seguite le parti precedenti di questa serie, è necessario avere la configurazione seguente pronta per procedere:

• Nginx è configurato per ospitare due siti Web:
  • La prima è in ascolto delle richieste usando l'intestazione host myfirstwebsite (http://myfirstwebsite) e le richieste di routing alla demo ASP.NET'applicazione Core in ascolto sulla porta 5000.
  • Il secondo è in ascolto delle richieste usando l'intestazione host buggyamb (http://buggyamb) e le richieste di routing alla seconda applicazione buggy di esempio ASP.NET Core in ascolto sulla porta 5001.
• Entrambe le applicazioni core ASP.NET devono essere eseguite come servizi che vengono riavviati automaticamente quando il server viene riavviato o l'applicazione smette di rispondere.
• Il firewall locale Linux è abilitato e configurato per consentire il traffico SSH e HTTP.

Note

Se la configurazione non è pronta, passare a "Parte 2 Creare ed eseguire ASP.NET app core".

Per continuare questo lab, è necessario avere almeno un problema ASP.NET'applicazione Web Core in esecuzione dietro Nginx.

Obiettivo di questo lab

Questo articolo è il secondo di due parti del lab per il debug di arresti anomali delle applicazioni ASP.NET Core in Linux.

In Lab 1.1 Riprodurre e risolvere un problema di arresto anomalo del sistema sono stati eseguiti i passaggi per riprodurre un problema di arresto anomalo e avviare la risoluzione dei problemi. È stato controllato Nginx e i log di sistema e si è continuato a risolvere i problemi raccogliendo e analizzando un file di dump della memoria. È stato estratto il file di dump core di arresto anomalo del sistema generato da apport, core dump file manager di Ubuntu.

In questa parte si installerà e si configurerà il debugger lldb per lavorare insieme all'estensione del debugger .NET Core denominata SOS e quindi si aprirà il file dump in lldb per analizzarlo.

Installare lldb

Per questo lab, è necessario installare lldb 3.9 o una versione successiva. Le istruzioni per diverse distribuzioni linux sono descritte in Installazione di LLDB in Linux. Per questa sezione, è consigliabile usare il apt comando install: sudo apt install lldb. Nello screenshot seguente è possibile vedere che lldb-6.0 è installato insieme ad alcune dipendenze.

Al termine dell'installazione, è necessario configurare lldb in modo che possa caricare automaticamente SOS all'apertura di un file di dump principale.

Configurare lldb

Prima di aprire il file di dump principale in lldb, seguire questa procedura necessaria per impostare il percorso del simbolo, scaricare i simboli e caricare automaticamente soS all'apertura di lldb:

1. Installare lo strumento dotnet-symbol:

   dotnet tool install -g dotnet-symbol

2. Scaricare i simboli per il file di dump di destinazione:

   dotnet-symbol <path_of_dump_file>

3. Installare SOS:

   1. Installare lo strumento globale dotnet-sos:

      dotnet tool install -g dotnet-sos

   2. Installare SOS:

      dotnet-sos install

Installare lo strumento dotnet-symbol

È necessario aver già installato lo strumento dotnet-symbol insieme agli strumenti dotnet-dump e dotnet-gcdump nella parte precedente. Se questi strumenti non sono ancora stati installati, installarli prima di procedere. A tale scopo, eseguire il dotnet tool install -g dotnet-symbol comando per installare dotnet-symbols. Se non è già stato fatto, installare dotnet-dump e dotnet-gcdump. A questo momento dovrebbero essere installati tre strumenti, come illustrato nello screenshot seguente.

Scaricare i simboli per il file dump

Nella parte 1 è stato illustrato come decomprimere il file di dump principale dal report di apport. È ora possibile scaricare i file di simboli. Come spiegato in questo articolo, i simboli operano a un livello elevato. Vengono usati come mapping tra il codice sorgente e i file binari. Questi mapping vengono usati dai debugger per risolvere i nomi della funzione o dei metodi, le informazioni sulla riga di origine o i nomi delle variabili locali quando leggono uno stack di chiamate.

Si userà il dotnet-symbol ~/dumps/dotnet/CoreDump -o ~/dumps/symbols --host-only comando per scaricare i simboli per il file di dump della memoria nella ~/dumps/symbols directory.

È possibile che vengano visualizzati diversi messaggi di errore "HTTP 404 not found" quando si scaricano i file di simboli se non si aggiunge l'opzione --host-only . È possibile ignorare questi errori. Il --host-only parametro scaricherà solo il programma host. Questo è tutto ciò che lldb deve avviare il debug dell'applicazione ASP.NET Core.

Il passaggio successivo consiste nell'installare l'estensione di debug gestita da SOS. Verranno esposti i comandi di debug .NET necessari per eseguire l'analisi.

Installare SOS

Che cos'è SOS? In base alla documentazione ufficiale, SOS è un'estensione del debugger che consente a uno sviluppatore di controllare lo stato gestito di un'applicazione .NET, inclusi i ASP.NET Core e altri . Applicazioni basate su NET, ad esempio .NET WPF e .NET Windows Form. SOS è un'estensione multipiattaforma che può essere caricata da WinDbg o da un debugger cdb in Windows e da lldb in Linux e macOS.

Per installare SOS, è prima necessario installare lo strumento dotnet-sos seguente:

dotnet tool install -g dotnet-sos

Installare quindi SOS:

dotnet-sos install

Lo screenshot seguente mostra il risultato di un'installazione riuscita. Si noti che lo strumento dotnet-sos ha configurato il debugger lldb in modo che l'estensione SOS venga caricata automaticamente all'avvio del debugger.

Si è finalmente pronti per aprire il file di dump usando lldb.

Aprire il dump core in lldb

Per aprire il dump principale, è necessario usare lldb e la sintassi seguente:

lldb --core <dump path> <host-program>

<host-program> è il programma nativo che ha avviato l'applicazione .NET Core. Si tratta in genere di dotnet, a meno che l'applicazione non sia autonoma. Se si tratta di un'applicazione autonoma, questa variabile è il nome dell'applicazione senza l'estensione .dll .

Supponendo di seguire la procedura usando gli stessi nomi di cartella, il percorso del file di dump della memoria generato nella sezione precedente deve essere ~/dumps/dotnet/CoreDump. Di conseguenza, si eseguirà lldb --core ~/dumps/dotnet/CoreDump per aprire il file.

Lo screenshot seguente mostra il debugger lldb che ha aperto il file di dump della memoria.

Impostare i simboli

Tenere presente che i file di simboli sono stati scaricati usando il dotnet-symbol comando nella ~/dumps/symbols directory . Il primo comando da eseguire all'interno del debugger consiste nell'impostare il percorso del server dei simboli sulla directory impostata per i download dei simboli:

setsymbolserver -directory ~/dumps/symbols

Caricare quindi i simboli: loadsymbols

Eseguire i comandi lldb e SOS

Sono disponibili diversi comandi lldb. È possibile elencarli usando il help comando . Nell'elenco è possibile vedere che i comandi SOS sono elencati anche in comandi definiti dall'utente. SOS è un plug-in per lldb. È possibile recuperare le informazioni della Guida del plug-in usando lo stesso help comando.

Note

È possibile cancellare occasionalmente l'output lldb. A tale scopo, premere CTRL+L.

Per iniziare, esaminare lo stack di chiamate native del thread usando il bt comando ("back trace"). Questo comando mostra lo stack di chiamate del thread attivo.

Esaminare quindi lo stack di chiamate gestite usando il comando SOS clrstack .

Non dovrebbe essere possibile recuperare informazioni. La procedura dettagliata dello stack avrà esito negativo perché lo stack segnalato è incompleto. Questo è correlato a quanto descritto in precedenza: il file di dump di core generato automaticamente non può raccogliere tutti gli stati gestiti.

Ricordare anche che si è verificata un'eccezione e questo ha causato l'arresto anomalo del processo. Esaminare le informazioni sull'eccezione eseguendo il comando SOS pe .

Come si può notare nell'output, il pe comando visualizza le informazioni sull'ultima eccezione, se presente, generata nel thread corrente.

Il messaggio di eccezione in questo caso è una risorsa temporaneamente non disponibile. Tuttavia, il tipo di eccezione e i nomi delle funzioni non vengono risolti. I valori vengono invece indicati come sconosciuti.

Viene visualizzato anche l'indirizzo dell'eccezione. È possibile provare a passare questo indirizzo come parametro nel pe comando per verificare se sono disponibili altri dettagli. Quindi eseguire pe 00007F8244048538.

Note

In questo comando sostituire l'indirizzo con l'indirizzo visualizzato nel file di dump.

Anche se si desidera visualizzare gli oggetti a cui si fa riferimento nello stack, viene visualizzato lo stesso valore sconosciuto.

È possibile provare a recuperare altre informazioni selezionando un indirizzo di uno degli oggetti nello stack ed esaminando l'oggetto usando il dumpobj <address> comando .

Tuttavia, probabilmente si concluderà che questo comando avrà anche un effetto limitato perché restituisce solo messaggi sconosciuti. È il momento di interrompere l'uso del file di dump generato automaticamente. Eseguire il exit comando per terminare la sessione lldb.

Per riepilogare, il file di dump generato dal sistema fornisce alcune informazioni, ma mancano ancora alcune informazioni importanti. Nella parte successiva verrà presentato l'approccio consigliato per acquisire un dump di arresto anomalo del sistema.

Passaggi successivi

Lab 1.3 Risoluzione di un problema di arresto anomalo del sistema - Acquisire i dump di arresto anomalo del core con lo strumento createdump