Résolution des problèmes de labo 1.2 - Analyser les fichiers de vidage principal générés par le système dans le débogueur lldb

S’applique à : .NET Core 2.1, .NET Core 3.1, .NET 5

Cet article explique comment installer et configurer le débogueur lldb dans Linux, puis ouvrir et analyser les fichiers de vidage .NET Core générés par le système.

Prerequisites

La configuration minimale requise pour suivre ces laboratoires de résolution des problèmes consiste à disposer d’une application ASP.NET Core pour illustrer des problèmes de faible niveau de processeur et de hautes performances de l’UC.

Vous trouverez plusieurs exemples d’applications pour atteindre cet objectif sur Internet. Par exemple, vous pouvez télécharger et configurer l’exemple d’api web simple de Microsoft pour illustrer un comportement indésirable. Vous pouvez également utiliser l’application BuggyAmb ASP.NET Core comme exemple de projet.

Si vous avez suivi les parties précédentes de cette série, vous devez disposer de la configuration suivante prête à être effectuée :

• Nginx est configuré pour héberger deux sites web :
  • Le premier écoute les requêtes en utilisant l’en-tête de l’hôte myfirstwebsite (http://myfirstwebsite) et les demandes de routage vers l’application de démonstration ASP.NET Core qui écoute sur le port 5000.
  • La deuxième écoute les requêtes à l’aide de l’en-tête de l’hôte buggyamb (http://buggyamb) et du routage des requêtes vers la deuxième application d’exemple de bogue ASP.NET core qui écoute sur le port 5001.
• Les deux applications ASP.NET Core doivent s’exécuter en tant que services qui redémarrent automatiquement lorsque le serveur est redémarré ou que l’application cesse de répondre.
• Le pare-feu local Linux est activé et configuré pour autoriser le trafic SSH et HTTP.

Note

Si votre configuration n’est pas prête, accédez à « Partie 2 Créer et exécuter des applications ASP.NET Core ».

Pour continuer ce labo, vous devez avoir au moins un problème ASP.NET application web Core s’exécutant derrière Nginx.

Objectif de ce labo

Cet article est le deuxième des deux parties de labo pour le débogage des plantages d’applications ASP.NET Core sur Linux.

Dans Lab 1.1 Reproduire et résoudre un problème d’incident, vous avez suivi les étapes de reproduction d’un problème d’incident et démarré la résolution des problèmes. Vous avez vérifié Nginx et les journaux système, puis procédé à la résolution des problèmes en collectant et en analysant un fichier de vidage de mémoire. Vous avez extrait le fichier de vidage de base sur incident généré par apport, le gestionnaire de fichiers de vidage principal d’Ubuntu.

Dans cette partie, vous allez installer et configurer le débogueur lldb pour qu’il fonctionne avec l’extension de débogueur .NET Core nommée SOS, puis ouvrez le fichier de vidage dans lldb pour l’analyser.

Installer lldb

Pour ce labo, vous devez installer lldb 3.9 ou une version ultérieure. Les instructions de plusieurs distributions Linux sont détaillées dans l’installation de LLDB sur Linux. Pour cette section, nous vous recommandons d’utiliser la commande d’installation apt : sudo apt install lldb. Dans la capture d’écran suivante, vous pouvez voir que le lldb-6.0 est installé avec certaines dépendances.

Une fois l’installation terminée, vous devez configurer lldb afin qu’elle puisse charger automatiquement SOS lorsqu’un fichier de vidage principal est ouvert.

Configurer lldb

Avant d’ouvrir le fichier de vidage principal dans lldb, suivez les étapes requises pour définir le chemin d’accès aux symboles, télécharger les symboles et charger automatiquement le soS lorsque lldb est ouvert :

1. Installez l’outil dotnet-symbol :

   dotnet tool install -g dotnet-symbol

2. Téléchargez les symboles du fichier de vidage cible :

   dotnet-symbol <path_of_dump_file>

3. Installez SOS :

   1. Installez l’outil global dotnet-sos :

      dotnet tool install -g dotnet-sos

   2. Installez SOS :

      dotnet-sos install

Installer l’outil dotnet-symbol

Vous devez avoir déjà installé l’outil dotnet-symbol avec les outils dotnet-dump et dotnet-gcdump dans la partie précédente. Si vous n’avez pas encore installé ces outils, installez-les avant de continuer. Pour ce faire, exécutez la dotnet tool install -g dotnet-symbol commande pour installer dotnet-symbols. Installez dotnet-dump et dotnet-gcdump, si ce n’est déjà fait. Vous devez maintenant avoir trois outils installés, comme illustré dans la capture d’écran suivante.

Télécharger des symboles pour le fichier de vidage

Dans la partie 1, vous avez été invité à décompresser le fichier de vidage principal à partir du rapport d’apport. Maintenant, il est temps de télécharger les fichiers de symboles. Comme expliqué dans cet article, les symboles fonctionnent à un niveau élevé. Ils servent de mappages entre le code source et les fichiers binaires. Ces mappages sont utilisés par les débogueurs pour résoudre les noms de fonction ou de méthode, les informations de ligne source ou les noms de variables locales lorsqu’ils lisent une pile d’appels.

Vous utiliserez la dotnet-symbol ~/dumps/dotnet/CoreDump -o ~/dumps/symbols --host-only commande pour télécharger les symboles du fichier de vidage mémoire dans le ~/dumps/symbols répertoire.

Vous pouvez recevoir plusieurs messages d’erreur « HTTP 404 introuvables » lorsque vous téléchargez des fichiers de symboles si vous n’ajoutez pas le --host-only commutateur. Vous pouvez ignorer sans risque ces messages. Le --host-only paramètre télécharge uniquement le programme hôte. Il s’agit de tout ce que lldb doit commencer à déboguer l’application ASP.NET Core.

L’étape suivante consiste à installer l’extension de débogage gérée par SOS. Cela expose les commandes de débogage .NET requises pour exécuter l’analyse.

Installer SOS

Qu’est-ce que SOS ? Selon la documentation officielle, SOS est une extension de débogueur qui permet à un développeur d’inspecter l’état managé d’une application .NET, y compris le ASP.NET Core et d’autres. Applications basées sur NET telles que .NET WPF et .NET Windows Forms. SOS est une extension multiplateforme qui peut être chargée par WinDbg ou un débogueur cdb sur Windows et par lldb sur Linux et macOS.

Pour installer SOS, vous devez d’abord installer l’outil dotnet-sos suivant :

dotnet tool install -g dotnet-sos

Ensuite, installez SOS :

dotnet-sos install

La capture d’écran suivante montre le résultat d’une installation réussie. Notez que l’outil dotnet-sos a configuré le débogueur lldb afin que l’extension SOS soit chargée automatiquement au démarrage du débogueur.

Vous êtes enfin prêt à ouvrir le fichier de vidage à l’aide de lldb.

Ouvrir le vidage principal dans lldb

Pour ouvrir le vidage principal, vous devez utiliser lldb et la syntaxe suivante :

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

Il <host-program> s’agit du programme natif qui a démarré l’application .NET Core. Il s’agit généralement de dotnet, sauf si l’application est autonome. S’il s’agit d’une application autonome, cette variable est le nom de l’application sans l’extension .dll .

En supposant que vous suivez les mêmes noms de dossiers, le chemin d’accès au fichier de vidage mémoire que vous avez généré dans la section précédente doit être ~/dumps/dotnet/CoreDump. Par conséquent, vous allez exécuter lldb --core ~/dumps/dotnet/CoreDump pour ouvrir le fichier.

La capture d’écran suivante montre le débogueur lldb qui a ouvert le fichier de vidage de mémoire.

Définir des symboles

Rappelez-vous que vous avez téléchargé les fichiers de symboles à l’aide de la dotnet-symbol commande dans le ~/dumps/symbols répertoire. La première commande que vous devez exécuter à l’intérieur du débogueur consiste à définir le chemin du serveur de symboles sur le répertoire que vous définissez pour les téléchargements de symboles :

setsymbolserver -directory ~/dumps/symbols

Ensuite, chargez les symboles : loadsymbols

Exécuter des commandes lldb et SOS

Il existe plusieurs commandes lldb. Vous pouvez les répertorier à l’aide de la help commande. Dans la liste, vous pouvez voir que les commandes SOS sont également répertoriées sous commandes définies par l’utilisateur. SOS est un plug-in pour lldb. Vous pouvez récupérer les informations d’aide du plug-in à l’aide de la même help commande.

Note

Vous souhaiterez peut-être effacer la sortie lldb occasionnellement. Pour ce faire, appuyez sur Ctrl+L.

Pour commencer, examinez la pile des appels natifs du thread à l’aide de la bt commande (« back trace »). Cette commande affiche la pile des appels du thread actif.

Ensuite, examinez la pile des appels managés à l’aide de la commande SOS clrstack .

Vous ne devez pas pouvoir récupérer d’informations. La procédure de la pile échoue, car la pile signalée est incomplète. Ceci est lié à ce qui a été abordé précédemment : le fichier de vidage principal généré automatiquement ne peut pas collecter tous les états managés.

Rappelez-vous également qu’une exception s’est produite et que cela a provoqué le blocage du processus. Examinez les informations d’exception en exécutant la commande SOS pe .

Comme vous pouvez le voir dans la sortie, la pe commande affiche les informations relatives à la dernière exception, le cas échéant, qui a été levée dans le thread actuel.

Le message d’exception dans ce cas est une ressource temporairement indisponible. Toutefois, le type d’exception et les noms de fonction ne sont pas résolus. Au lieu de cela, leurs valeurs sont indiquées comme inconnues.

L’adresse de l’exception est également affichée. Vous pouvez essayer de passer cette adresse en tant que paramètre dans la pe commande pour voir si des détails supplémentaires sont disponibles. Exécutez ensuite pe 00007F8244048538.

Note

Dans cette commande, remplacez l’adresse par l’adresse affichée dans le fichier de vidage.

Même si vous souhaitez afficher les objets référencés dans la pile, vous voyez la même valeur inconnue.

Vous pouvez essayer de récupérer plus d’informations en sélectionnant une adresse de l’un des objets de la pile et en examinant l’objet à l’aide de la dumpobj <address> commande.

Toutefois, vous conclurez probablement que cette commande aura également un effet limité, car elle retourne uniquement des messages plus inconnus. Il est temps d’arrêter d’utiliser le fichier de vidage généré automatiquement. Exécutez la exit commande pour mettre fin à la session lldb.

Pour résumer, le fichier de vidage généré par le système vous fournit des informations, mais vous manquez toujours des informations importantes. Dans la partie suivante, vous allez présenter l’approche recommandée pour capturer un vidage sur incident.

Prochaines étapes

Lab 1.3 Résolution d’un problème d’incident - Capturer les vidages d’incident de base avec l’outil createdump