3.4. Débogage d'une application bloquée

Procédure

1. Pour activer les vidages de noyau, assurez-vous que le fichier /etc/systemd/system.conf contient les lignes suivantes :

   DumpCore=yes
   DefaultLimitCORE=infinity

   Vous pouvez également ajouter des commentaires décrivant si ces paramètres étaient présents auparavant, et quelles étaient les valeurs précédentes. Cela vous permettra d'annuler ces modifications ultérieurement, si nécessaire. Les commentaires sont des lignes commençant par le caractère #.

   La modification du fichier nécessite un accès de niveau administrateur.

2. Appliquer la nouvelle configuration :

   # systemctl daemon-reexec

3. Supprimer les limites de taille du core dump :

   # ulimit -c unlimited

   Pour inverser ce changement, exécutez la commande avec la valeur 0 au lieu de unlimited.

4. Installez le paquet sos qui fournit l'utilitaire sosreport pour collecter des informations sur le système :

   # dnf install sos

5. Lorsqu'une application se bloque, un core dump est généré et traité par systemd-coredump.

6. Créer un rapport SOS pour fournir des informations supplémentaires sur le système :

   # sosreport

   Cette opération crée une archive .tar contenant des informations sur votre système, telles que des copies des fichiers de configuration.

7. Localiser et exporter le core dump :

   $ coredumpctl list executable-name
   $ coredumpctl dump executable-name > /path/to/file-for-export

   Si l'application s'est écrasée plusieurs fois, la sortie de la première commande énumère davantage de vidages de noyau capturés. Dans ce cas, construisez pour la deuxième commande une requête plus précise en utilisant les autres informations. Voir la page de manuel coredumpctl(1) pour plus de détails.

8. Transférez le core dump et le rapport SOS sur l'ordinateur où le débogage aura lieu. Transférez également le fichier exécutable, s'il est connu.

   Important

   Lorsque le fichier exécutable n'est pas connu, l'analyse ultérieure du fichier central permet de l'identifier.

9. Facultatif : Supprimez le core dump et le rapport SOS après les avoir transférés, afin de libérer de l'espace disque.

Procédure

1. Pour identifier le fichier exécutable où le crash s'est produit, exécutez la commande eu-unstrip avec le fichier core dump :

   $ eu-unstrip -n --core=./core.9814
   0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
   0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
   0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
   0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

   La sortie contient les détails de chaque module sur une ligne, séparés par des espaces. Les informations sont listées dans cet ordre :

   1. L'adresse mémoire où le module a été mappé
   2. L'identifiant de construction du module et l'endroit où il a été trouvé dans la mémoire
   3. Le nom du fichier exécutable du module, affiché sous la forme - s'il est inconnu, ou sous la forme . si le module n'a pas été chargé à partir d'un fichier
   4. La source des informations de débogage, affichée sous la forme d'un nom de fichier lorsqu'elle est disponible, sous la forme de . lorsqu'elle est contenue dans le fichier exécutable lui-même, ou sous la forme de - lorsqu'elle n'est pas présente du tout
   5. Le nom de la bibliothèque partagée (soname) ou [exe] pour le module principal

   Dans cet exemple, les détails importants sont le nom du fichier /usr/bin/sleep et le build-id 2818b2009547f780a5639c904cded443e564973e sur la ligne contenant le texte [exe]. Grâce à ces informations, vous pouvez identifier le fichier exécutable nécessaire à l'analyse du core dump.

2. Obtenir le fichier exécutable qui s'est écrasé.

   • Si possible, copiez-le à partir du système où la panne s'est produite. Utilisez le nom du fichier extrait du fichier principal.

   • Vous pouvez également utiliser un fichier exécutable identique sur votre système. Chaque fichier exécutable construit sur Red Hat Enterprise Linux contient une note avec une valeur build-id unique. Déterminez le build-id des fichiers exécutables pertinents disponibles localement :

     $ eu-readelf -n executable_file

     Utilisez ces informations pour faire correspondre le fichier exécutable du système distant avec votre copie locale. Le build-id du fichier local et le build-id listé dans le core dump doivent correspondre.

   • Enfin, si l'application est installée à partir d'un paquetage RPM, vous pouvez obtenir le fichier exécutable à partir du paquetage. Utilisez la sortie de sosreport pour trouver la version exacte du paquetage requis.
3. Obtenez les bibliothèques partagées utilisées par le fichier exécutable. Utilisez les mêmes étapes que pour le fichier exécutable.
4. Si l'application est distribuée sous forme de paquetage, chargez le fichier exécutable dans GDB, afin d'afficher des indications sur les paquets debuginfo manquants. Pour plus de détails, voir Section 3.1.4, « Obtenir les paquets d'informations de débogage pour une application ou une bibliothèque à l'aide de GDB ».

5. Pour examiner le fichier core en détail, chargez le fichier exécutable et le fichier core dump avec GDB :

   $ gdb -e executable_file -c core_file

   D'autres messages concernant les fichiers manquants et les informations de débogage vous aident à identifier ce qui manque pour la session de débogage. Revenez à l'étape précédente si nécessaire.

   Si les informations de débogage de l'application sont disponibles sous la forme d'un fichier et non d'un paquet, chargez ce fichier dans GDB à l'aide de la commande symbol-file:

   (gdb) fichier-symbole program.debug

   Remplacez program.debug par le nom réel du fichier.

   Note

   Il n'est peut-être pas nécessaire d'installer les informations de débogage pour tous les fichiers exécutables contenus dans le core dump. La plupart de ces fichiers exécutables sont des bibliothèques utilisées par le code de l'application. Ces bibliothèques peuvent ne pas contribuer directement au problème que vous analysez et vous n'avez pas besoin d'inclure les informations de débogage les concernant.

6. Utilisez les commandes GDB pour inspecter l'état de l'application au moment où elle s'est arrêtée. Voir Inspection de l'état interne de l'application avec GDB.

   Note

   Lors de l'analyse d'un fichier core, GDB n'est pas attaché à un processus en cours d'exécution. Les commandes de contrôle de l'exécution n'ont aucun effet.

Procédure

1. Trouver le PID du processus suspendu, sur la base d'une partie connue du nom du fichier exécutable :

   $ pgrep -a executable-name-fragment

   Cette commande produira une ligne sous la forme

   PID command-line

   Utilisez la valeur command-line pour vérifier que le site PID appartient au processus prévu.

   Par exemple :

   $ pgrep -a bc
   5459 bc

2. Envoyer un signal d'abandon au processus :

   # kill -ABRT PID

3. Vérifiez que le noyau a été capturé par coredumpctl:

   $ coredumpctl list PID

   Par exemple :

   $ coredumpctl list 5459
   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. Examiner plus avant ou utiliser le fichier de base selon les besoins.

   Vous pouvez spécifier le core dump par PID et d'autres valeurs. Voir la page de manuel coredumpctl(1) pour plus de détails.

   • Pour afficher les détails du fichier principal :

     $ coredumpctl info PID

   • Pour charger le fichier core dans le débogueur GDB :

     $ coredumpctl debug PID

     En fonction de la disponibilité des informations de débogage, GDB suggérera des commandes à exécuter, telles que :

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     Pour plus de détails sur ce processus, voir Obtenir des paquets d'informations de débogage pour une application ou une bibliothèque à l'aide de GDB.

   • Pour exporter le fichier de base en vue d'un traitement ultérieur ailleurs :

     $ coredumpctl dump PID > /path/to/file_for_export

     Remplacez /path/to/file_for_export par le fichier dans lequel vous souhaitez placer le core dump.

Procédure

1. Trouvez l'identifiant du processus (pid). Utilisez des outils tels que ps, pgrep, et top:

   $ ps -C some-program

2. Vider la mémoire de ce processus :

   $ gcore -o filename pid

   Cette opération crée un fichier filename et y déverse la mémoire du processus. Pendant que la mémoire est vidée, l'exécution du processus est interrompue.

3. Une fois le vidage du noyau terminé, le processus reprend son cours normal.

4. Créer un rapport SOS pour fournir des informations supplémentaires sur le système :

   # sosreport

   Cette opération crée une archive tar contenant des informations sur votre système, telles que des copies des fichiers de configuration.

5. Transférez le fichier exécutable du programme, le core dump et le rapport SOS sur l'ordinateur où le débogage aura lieu.
6. Facultatif : Supprimez le core dump et le rapport SOS après les avoir transférés, afin de libérer de l'espace disque.

Procédure

1. Configurer GDB pour qu'il ignore les paramètres du fichier /proc/PID/coredump_filter:

   (gdb) set use-coredump-filter off

2. Configure GDB pour qu'il ignore le drapeau de page mémoire VM_DONTDUMP:

   (gdb) set dump-excluded-mappings on

3. Vider la mémoire :

   (gdb) gcore core-file

   Remplacez core-file par le nom du fichier dans lequel vous voulez vider la mémoire.