Condividi tramite

Eseguire il debug di dump di Linux

  • Articolo

Questo articolo si applica a: ✔️ .NET Core 3.0 SDK e versioni successive

Raccogliere dump in Linux

Suggerimento

Per domande frequenti sulla raccolta di dump, l'analisi e altre puntualizzazioni, vedere Dump: domande frequenti.

I due modi consigliati per raccogliere i dump in Linux sono i seguenti:

Analizzare i dump in Linux

Dopo aver raccolto un dump, è possibile analizzarlo usando lo strumento dotnet-dump con il comando dotnet-dump analyze. Questo passaggio di analisi deve essere eseguito in un computer con la stessa architettura e distribuzione di Linux dell'ambiente in cui è stato acquisito il dump. Lo strumento dotnet-dump supporta la visualizzazione di informazioni sul codice .NET, ma non è utile per comprendere i problemi del codice per altri linguaggi come C e C++.

In alternativa, per analizzare i dump in Linux è possibile usare LLDB, che consente l'analisi del codice gestito e nativo. LLDB usa l'estensione SOS per eseguire il debug del codice gestito. Lo strumento dell'interfaccia della riga di comando dotnet-sos può essere usato per installare SOS, che include molti comandi utili per il debug del codice gestito. Per analizzare i dump di .NET Core, LLDB e SOS richiedono i file binari di .NET Core seguenti dall'ambiente in cui è stato creato il dump:

  1. libmscordaccore.so
  2. libcoreclr.so
  3. dotnet (l'host usato per avviare l'app)

Nella maggior parte dei casi, questi file binari possono essere scaricati usando lo strumento dotnet-symbol. Se i file binari necessari non possono essere scaricati con dotnet-symbol (ad esempio, se è stata usata una versione privata di .NET Core compilata dall'origine), potrebbe essere necessario copiare i file elencati in precedenza dall'ambiente in cui è stato creato il dump. Se i file non si trovano vicini al file dump, è possibile usare il comando setclrpath <path> LLDB/SOS per impostare il percorso da cui devono essere caricati e setsymbolserver -directory <path> per impostare il percorso in cui cercare i file di simboli.

Una volta disponibili i file necessari, il dump può essere caricato in LLDB specificando l'host dotnet come eseguibile per il debug:

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

Nel comando precedente <dump-file> è il percorso del dump da analizzare e <host-program> è il programma nativo che ha avviato l'applicazione .NET Core. Si tratta in genere del file binario dotnet a meno che l'app non sia autonoma, nel qual caso è il nome dell'applicazione senza l'estensione .dll.

Dopo l'avvio di LLDB, potrebbe essere necessario usare il comando setsymbolserver per puntare al percorso dei simboli corretto (setsymbolserver -ms per usare il server dei simboli di Microsoft o setsymbolserver -directory <path> per specificare un percorso locale). Per caricare i simboli nativi, eseguire loadsymbols. A questo punto, è possibile usare i comandi SOS per analizzare il dump.

Nota

LLDB può essere installato con il comando sudo apt-get install lldb

Analizzare i dump in Windows

I dump raccolti da un computer Linux possono anche essere analizzati in un computer Windows usando Visual Studio, Windbg o lo strumento dotnet-dump. Sia Visual Studio che Windbg possono analizzare codice nativo e gestito, mentre dotnet-dump analizza solo il codice gestito.

Nota

Visual Studio 16.8 e versione successiva consente di aprire e analizzare i dump di Linux generati in .NET Core 3.1.7 o versione successiva.

  • Visual Studio - Vedere la guida al debug del dump di Visual Studio.
  • Windbg - È possibile eseguire il debug dei dump di Linux in windbg usando le stesse istruzioni valide per eseguire il debug di un dump in modalità utente di Windows. Usare la versione x64 di windbg per i dump raccolti da un ambiente Linux x64 o Arm64 e la versione x86 per i dump raccolti da un ambiente Linux x86.
  • dotnet-dump - Visualizzare il dump usando il comando dotnet-dump analyze. Usare la versione x64 di dotnet-dump per i dump raccolti da un ambiente Linux x64 o Arm64 e la versione x86 per i dump raccolti da un ambiente Linux x86.

Vedi anche