Partie 3.3 - Débogueurs, vidages de cœurs et collecte des vidages de cœurs

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

Cet article présente les débogueurs et les vidages principaux et les outils permettant de capturer et d’analyser les fichiers de vidage principaux dans Linux.

Prerequisites

Comme dans les parties précédentes, cette partie est structurée pour mettre davantage l’accent sur la théorie et les principes à suivre lorsque vous commencez à résoudre les problèmes. Elle n’a aucun prérequis. Toutefois, vous devez avoir déjà configuré les éléments suivants si vous avez suivi toutes les étapes de cette formation jusqu’à présent :

• Nginx a deux sites web :
  • Le premier site web écoute les requêtes à l’aide de l’en-tête de l’hôte myfirstwebsite (http://myfirstwebsite) et route les requêtes vers l’application demo ASP.NET Core qui écoute sur le port 5000.
  • Le deuxième site web écoute les requêtes à l’aide de l’en-tête de l’hôte buggyamb (http://buggyamb) et route les requêtes vers la deuxième application ASP.NET Core de bogues qui écoute sur le port 5001.
• Les deux applications ASP.NET Core s’exécutent en tant que services qui redémarrent automatiquement lorsque le serveur est redémarré, ou les applications cesse de répondre ou échouent.
• Un pare-feu local Linux est activé et configuré pour autoriser le trafic SSH et HTTP.

Objectif de cette partie

Cette partie présente le concept de vidages et de débogueurs principaux, ainsi que les outils que vous pouvez utiliser pour capturer et analyser les fichiers de vidage principaux. La plupart des techniques et outils décrits dans cette partie seront utilisés dans les laboratoires de résolution des problèmes suivants.

Vidage principal

Tout comme un vidage de mémoire en mode utilisateur dans Windows, un vidage principal est un instantané de la mémoire d’un processus. Les vidages principaux sont fréquemment nécessaires pour résoudre les problèmes de performances dans Linux.

Un vidage principal peut être généré à la demande par un débogueur (collecte manuelle de vidage) ou être configuré pour être collecté automatiquement après une défaillance du processus.

Que se passe-t-il lorsqu’un processus échoue dans Linux ?

La plupart des systèmes Linux ont des vidages principaux activés par défaut. Le système génère un vidage de base pour tout processus qui est arrêté de façon inattendue. Cela est similaire à la façon dont windows Error Reporting (WER) génère des vidages pour les processus qui se terminent anormalement.

Voici quelques aspects clés de la façon dont un système Linux se comporte en lien avec la génération de fichiers de vidage de base :

• Par défaut, un fichier de vidage principal est généré lorsqu’un processus est arrêté de façon inattendue.
• Le fichier de vidage principal est nommé « core » et est créé dans le répertoire de travail actif ou dans le /var/lib/systemd/coredump répertoire.
• Bien que le comportement par défaut soit pour que le système d’exploitation génère un fichier de vidage principal, ce paramètre peut être remplacé pour /proc/sys/kernel/core_pattern diriger directement la sortie du fichier de vidage principal dans une autre application.

Ces paramètres par défaut et d’autres, tels que les limites de taille, peuvent être définis dans les fichiers de configuration. Les ressources suivantes sont plus approfondies sur ce sujet :

• Vidages de base

• Lien externe : cœur de page De l’utilisateur Ubuntu - fichier de vidage principal

Apport : La façon d’Ubuntu de gérer les vidages principaux

Dans Ubuntu, le service système d’apport gère la génération de vidage de base. Même si la génération de vidage de base du système d’exploitation est désactivée, l’apport crée toujours des fichiers de vidage de base.

Apport utilise /proc/sys/kernel/core_pattern pour diriger directement le fichier de vidage principal en apport. Si vous exécutez la cat /proc/sys/kernel/core_pattern commande pendant l’exécution de l’apport, vous devez voir le résultat suivant.

Si vous désactivez l’apport, cela n’empêche pas la génération de vidage de base lors de l’arrêt du processus. Au lieu de cela, il arrête simplement l’apport. Le système revient ensuite à son comportement par défaut en générant des vidages principaux lui-même. Si vous exécutez la même cat /proc/sys/kernel/core_pattern opération après l’arrêt de l’apport, vous verrez le comportement système par défaut suivant.

Désactiver la génération automatique de vidage de base

Pour désactiver la génération automatique de fichiers de vidage de base, procédez comme suit :

1. Arrêtez et désactivez l’apport.
2. Désactivez l’action par défaut du système.

L’apport peut être arrêté et désactivé de la même façon que n’importe quel autre service. Utilisez la sudo systemctl stop apport commande et la sudo systemctl disable apport commande pour arrêter le service, puis désactivez-la pour empêcher son redémarrage.

Pour désactiver la génération automatique du fichier de vidage du système d’exploitation pour tous les processus qui s’exécutent sous tous les comptes d’utilisateur sur l’ordinateur, vous devez suivre les étapes fournies dans des articles tels que celui-ci.

Capturer le vidage principal et les débogueurs

Plusieurs outils sont disponibles pour capturer un fichier de vidage principal, tel que gcore, gdb et plusieurs outils pour analyser un fichier de vidage principal, tel que objdump, kdump, gdb et lldb.

Toutefois, vous rencontrerez des difficultés importantes lorsque vous travaillez avec ces outils pour essayer de déboguer .NET :

• La configuration peut être difficile par rapport au processus de configuration des symboles pour le débogueur WinDbg sur Windows.
• Les fichiers de vidage de base sont volumineux, car ces outils ne savent pas quelle région de mémoire est utilisée dans un processus .NET Core, et ils ne peuvent pas découper les informations de mémoire uniquement sur ce qui est nécessaire.
• Les fichiers de vidage ne sont pas portables. Vous devrez analyser les fichiers de vidage sur l’ordinateur Linux sur lequel ils ont été générés. Si vous souhaitez analyser les fichiers de vidage sur différents ordinateurs Linux, des étapes supplémentaires sont nécessaires pour configurer l’ordinateur hôte pour la session de débogage.

lldb

Lldb est l’outil recommandé pour l’analyse du vidage .NET Core. Le Kit de développement logiciel (SDK) .NET inclut des outils utiles pour configurer lldb correctement. Toutefois, vous devez installer au moins la version 3.9 pour pouvoir effectuer cette analyse de débogage pour .NET Core.

Pour installer lldb 3.9 ou une version ultérieure, utilisez Gestionnaire de package (par exemple : sudo apt install lldb).

Outils et commandes disponibles dans le runtime et le Kit de développement logiciel (SDK) .NET Core

Plusieurs outils utiles sont inclus avec le runtime .NET Core. Par exemple, createdump est installé dans le cadre de chaque installation d’exécution de .NET Core.

Vous pouvez également développer vos propres outils ou choisir d’utiliser plusieurs outils tiers. La plateforme Microsoft .NET Core inclut également certains outils .NET Core qui sont utiles pour déboguer des problèmes .NET Core. Leurs thèmes sont les suivants :

• dotnet-dump
• dotnet-gcdump
• dotnet-symbol

Pour installer ces outils avec les autres, vous devez installer le Kit de développement logiciel (SDK) .NET Core. Pour plus d’informations sur le Kit de développement logiciel (SDK) .NET Core, consultez : Vue d’ensemble du Kit de développement logiciel (SDK) .NET.

Note

Procdump est également digne d’une mention, bien qu’il ne fait pas partie du Kit de développement logiciel (SDK). Une discussion approfondie sur les options ProcDump est disponible à la fin de cette partie.

createdump

Createdump est installé dans chaque version de .NET Core. Pour plus d’informations, consultez les détails de l’implémentation.

Createdump est le meilleur moyen de générer un fichier de vidage principal dans Linux. Cela est dû au fait que les fichiers de vidage générés automatiquement par le système peuvent ne pas inclure tous les états managés. En outre, certaines commandes SOS ou dotnet-dump peuvent afficher « UNKNOWN » pour les noms de type et de fonction.

De même, les fichiers de vidage manuels créés à l’aide de gdb ou gcore n’incluent pas toutes les informations d’état managé, et certaines commandes SOS ou dotnet-dump peuvent également afficher « UNKNOWN » pour les noms de type et de fonction. La méthode recommandée pour capturer des fichiers de vidage manuel consiste à utiliser createdump ou un autre outil .NET Core, tel que procdump.

Voici quelques fonctionnalités importantes de createdump :

• Les minidumps de taille minimale sont générés automatiquement.
• Il est facile de configurer avec un utilisateur non racine.
• Vous pouvez l’utiliser pour capturer des fichiers de vidage de base à la demande (manuel) ou système.
• La plupart des échecs de dépassement de pile sont détectés.

Vous devez utiliser lldb 3.9 ou une version ultérieure pour analyser les fichiers de vidage principaux capturés à l’aide de createdump.

Vous pouvez trouver l’énumération créée dans le répertoire d’installation de .NET Core. Pour rechercher ce répertoire, exécutez la dotnet --list-runtimes commande. Comme illustré dans la capture d’écran suivante, un fichier créé distinct a été créé pour les deux versions des runtimes actifs.

dotnet-dump

Vous devez installer le Kit de développement logiciel (SDK) .NET Core pour pouvoir installer cet outil. Dotnet-dump a été introduit dans le Kit de développement logiciel (SDK) .NET Core 3.0. Il permet de collecter et d’analyser les fichiers de vidage principaux sans avoir besoin d’un débogueur natif. Il vous permet d’exécuter des commandes SOS pour analyser les échecs et la sortie du garbage collector (GC).

Note

Dotnet-dump n’est pas un débogueur natif. Par conséquent, certaines fonctionnalités, telles que l’affichage des trames de pile natives, ne sont pas disponibles. Le fichier de vidage généré n’est pas portable et vous ne pouvez pas l’ouvrir dans Windows.

Pour installer cet outil, exécutez la commande suivante :

dotnet tool install -g dotnet-dump

Vous allez utiliser cet outil pour capturer et analyser les fichiers de vidage principaux dans les sections du labo à venir.

dotnet-gcdump

Il s’agit d’un autre outil qui nécessite le Kit de développement logiciel (SDK) .NET Core. Dotnet-gcdump est disponible dans .NET Core 3.1 ou versions ultérieures.

Il s’agit d’une approche intéressante pour l’analyse des tas GC. L’idée derrière cet outil est qu’un fichier de vidage de processus complet n’est pas nécessaire pour les enquêtes dans de nombreux scénarios. Par conséquent, l’outil capture uniquement les informations de tas managées et génère un rapport en fonction de celui-ci.

Plus important encore, les fichiers de vidage générés par cet outil sont portables et peuvent être analysés dans PerfView ou Visual Studio dans Windows.

Comme expliqué brièvement ici, un garbage collection complet est déclenché par cet outil pour diffuser en continu les informations vers un « canal d’événement » pour générer le fichier de vidage.

Note

Étant donné qu’un garbage collection Gen 2 complet est déclenché dans le processus cible, les caractéristiques de performances de l’application peuvent être modifiées. Comme vous pouvez vous attendre, alors que les informations sont écrites dans le fichier de vidage principal, les threads sont suspendus. Plus la taille du tas est grande, plus les pauses sont les pauses pour écrire les informations dans le fichier, et plus les threads restent suspendus.

Les informations contenues dans ces fichiers de vidage de base seront utiles dans les circonstances suivantes :

• Comparaison du nombre d’objets par type sur le tas managé
• Analyse des racines d’objet
• Détermination des objets qui ont une référence à quel type
• Autres analyses statistiques sur les objets sur le tas

Une fois les données générées, le fichier peut être exporté en dehors de l’ordinateur sur lequel il a été créé, et il peut être analysé dans PerfView ou dans Visual Studio.

Pour installer cet outil, exécutez la commande suivante :

dotnet tool install -g dotnet-gcdump

Vous allez utiliser cette commande pour générer des rapports pour les tas .NET Core dans les sections du labo à venir.

dotnet-symbol

Dotnet-symbol est un outil utile pour obtenir des symboles pour le débogage managé. Il a été introduit dans .NET Core 2.1. Comme pour les deux autres outils mentionnés précédemment, ces outils nécessitent également l’installation du Kit de développement logiciel (SDK) .NET Core.

Dotnet-symbol télécharge tous les fichiers nécessaires au débogage (symboles, modules, SOS et DAC pour le module coreclr) pour les fichiers de vidage principaux donnés.

Pour installer cet outil, exécutez la commande suivante :

dotnet tool install -g dotnet-symbol

Vous allez utiliser cet outil pour configurer le débogueur dans les sections du labo à venir.

procdump

Une version Linux de ProcDump est également disponible. Il a quelques ensembles de fonctionnalités limités par rapport à son équivalent Windows. Elle ne prend pas en charge chaque fonctionnalité que fait la version de Windows. Par exemple, il ne peut pas être configuré pour collecter les fichiers de vidage principaux lorsque le processus plante ou lève une exception de première chance. Toutefois, il s’agit toujours d’un outil puissant.

Les options de ligne de commande suivantes pour la génération des fichiers de vidage principaux de ProcDump dans les conditions spécifiées.

-C: CPU exceeds or equals a specified value (0 to 100 * nCPU)
-c: CPU is less than a specified value (0 to 100 * nCPU)
-M: The memory commit exceeds or equals a specified value (MB)
-m: The memory commit is less than a specified value (MB)
-T: The thread count exceeds or equals a specified value
-F: The filedescriptor count exceeds or equals a specified value

Suivez les instructions d’installation pour installer ProcDump dans votre environnement.

Vous allez utiliser cet outil pour capturer un fichier de vidage principal basé sur l’utilisation du processeur dans les sections du labo à venir.

Remarque sur la sélection de la version du Kit de développement logiciel (SDK)

Par défaut, le Kit de développement logiciel (SDK) s’installe dans une configuration « côte à côte ». Cela signifie que plusieurs versions peuvent s’exécuter ensemble sur un seul ordinateur. Pour plus d’informations sur la façon dont la version est choisie lorsque vous exécutez des commandes CLI, consultez l’article Sélectionner la version .NET Core à utiliser. Toutefois, le processus de sélection d’une version du Kit de développement logiciel (SDK) peut être résumé comme suit :

• .NET Core recherche un fichier d’global.json de manière itérative en parcourant de manière itérative le chemin vers le haut à partir du répertoire de travail actuel.
• .NET Core utilise le Kit de développement logiciel (SDK) spécifié dans la première global.json trouvée.
• .NET Core utilise le kit SDK installé le plus récent si aucune instance global.json est trouvée.

Par exemple, sur la machine virtuelle Linux de test, vous devez avoir installé les kits SDK .NET Core 3.1 et 5.0. Si vous exécutez .NET Core en incluant le --version commutateur, vous devez voir que la dernière version est utilisée.

À présent, créez un fichier global.json dans le répertoire actif (votre répertoire de base) et définissez la version explicitement à l’aide de l’outil cat, comme indiqué. Ensuite, vérifiez à nouveau la version. Il affiche maintenant la version exacte du Kit de développement logiciel (SDK) que vous avez placée dans le fichier global.json .

Il est important de savoir quand vous exécutez certaines commandes du Kit de développement logiciel (SDK), telles que la création d’une application à l’aide de la commande .NET Core new . Toutefois, vous n’aurez pas à le faire lorsque vous utilisez les outils dotnet-dump et dotnet-gcdump.

Le Kit de développement logiciel (SDK) .NET Core installe la dernière version des outils, quel que soit le SDK que vous avez sélectionné. Par exemple, si vous avez exécuté les commandes pour installer dotnet-dump, dotnet-gcdump et dotnet-symbol tools for .NET Core SDK 3.1, les dernières versions de ces outils seront téléchargées et installées, comme illustré dans la capture d’écran suivante (où la version 5 des outils pour dotnet-dump et dotnet-gcdump ont été installées).

Les articles suivants sont des ressources intéressantes pour plus d’informations sur les outils .NET Core :

• Guide pratique pour gérer les outils .NET

• dotnet tool install

Note

La sélection de la version du runtime à utiliser est différente de la sélection de la version du Kit de développement logiciel (SDK). Si vous souhaitez utiliser une version spécifique du runtime .NET, utilisez l’option --fx-version VERSION<>, comme expliqué dans cet article.

Prochaines étapes

Vous êtes maintenant prêt à commencer les laboratoires de résolution des problèmes. Dans les laboratoires, vous allez apprendre à utiliser les outils abordés ici pour résoudre les problèmes.

Lab 1.1 Reproduire et résoudre un problème d’incident