1. Les fichiers sources sont compilés en fichiers objets.
2. Les fichiers objets et les bibliothèques sont liés (y compris les sources compilées précédemment).

Procédure

1. Se rendre dans le répertoire contenant le(s) fichier(s) du code source.

2. Exécutez gcc avec l'option -c:

   $ gcc -c source.c another_source.c

   Des fichiers objets sont créés, dont les noms reflètent les fichiers du code source original : source.c donne lieu à source.o.

   Note

   Avec le code source C, remplacez la commande gcc par g pour une gestion pratique des dépendances de la bibliothèque standard C.

Procédure

1. Se rendre dans le répertoire contenant le(s) fichier(s) de code objet.

2. Exécuter gcc:

   $ gcc ... objfile.o another_object.o... -o executable-file

   Un fichier exécutable nommé executable-file est créé à partir des fichiers objets et des bibliothèques fournis.

   Pour lier des bibliothèques supplémentaires, ajoutez les options requises après la liste des fichiers objets.

   Note

   Avec le code source C, remplacez la commande gcc par g pour une gestion pratique des dépendances de la bibliothèque standard C.

Procédure

1. Créez un répertoire hello-c et accédez-y :

   $ mkdir hello-c
   $ cd hello-c

2. Créez le fichier hello.c avec le contenu suivant :

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. Compiler et lier le code avec GCC :

   $ gcc hello.c -o helloworld

   Cette opération compile le code, crée le fichier objet hello.o et lie le fichier exécutable helloworld à partir du fichier objet.

4. Exécutez le fichier exécutable obtenu :

   $ ./helloworld
   Hello, World!

Procédure

1. Créez un répertoire hello-c et accédez-y :

   $ mkdir hello-c
   $ cd hello-c

2. Créez le fichier hello.c avec le contenu suivant :

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. Compilez le code avec GCC :

   $ gcc -c hello.c

   Le fichier objet hello.o est créé.

4. Lier un fichier exécutable helloworld à partir du fichier objet :

   $ gcc hello.o -o helloworld

5. Exécutez le fichier exécutable obtenu :

   $ ./helloworld
   Hello, World!

Procédure

1. Créez un répertoire hello-cpp et accédez-y :

   $ mkdir hello-cpp
   $ cd hello-cpp

2. Créez le fichier hello.cpp avec le contenu suivant :

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. Compiler et lier le code avec g :

   $ g++ hello.cpp -o helloworld

   Cette opération compile le code, crée le fichier objet hello.o et lie le fichier exécutable helloworld à partir du fichier objet.

4. Exécutez le fichier exécutable obtenu :

   $ ./helloworld
   Hello, World!

Procédure

1. Créez un répertoire hello-cpp et accédez-y :

   $ mkdir hello-cpp
   $ cd hello-cpp

2. Créez le fichier hello.cpp avec le contenu suivant :

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. Compilez le code avec g :

   $ g++ -c hello.cpp

   Le fichier objet hello.o est créé.

4. Lier un fichier exécutable helloworld à partir du fichier objet :

   $ g++ hello.o -o helloworld

5. Exécutez le fichier exécutable obtenu :

   $ ./helloworld
   Hello, World!

1. Allez dans le répertoire contenant votre code.

2. Compiler les fichiers sources du programme avec les en-têtes de la bibliothèque foo:

   $ gcc ... -Iheader_path -c ...

   Remplacez header_path par un chemin vers un répertoire contenant les fichiers d'en-tête de la bibliothèque foo.

3. Lier le programme à la bibliothèque foo:

   $ gcc ... -Llibrary_path -lfoo...

   Remplacez library_path par un chemin d'accès à un répertoire contenant le fichier libfoo.a.

4. Pour exécuter le programme ultérieurement, il suffit de

   $ ./program

Procédure

1. Se rendre dans le répertoire contenant les sources de la bibliothèque.

2. Compilez chaque fichier source en un fichier objet avec l'option de code indépendant de la position -fPIC:

   $ gcc ... -c -fPIC some_file.c...

   Les fichiers objets portent le même nom que les fichiers du code source original, mais leur extension est .o.

3. Lier la bibliothèque partagée à partir des fichiers objets :

   $ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...

   Le numéro de version majeure utilisé est X et le numéro de version mineure Y.

4. Copier le fichier libfoo.so.x.y à un emplacement approprié, où l'éditeur de liens dynamiques du système peut le trouver. Sur Red Hat Enterprise Linux, le répertoire des bibliothèques est /usr/lib64:

   # cp libfoo.so.x.y /usr/lib64

   Notez que vous devez disposer des droits de root pour manipuler les fichiers de ce répertoire.

5. Créer la structure de lien symbolique pour le mécanisme de soname :

   # ln -s libfoo.so.x.y libfoo.so.x
   # ln -s libfoo.so.x libfoo.so

Procédure

1. Créer des fichiers objets intermédiaires avec GCC.

   $ gcc -c source_file.c...

   Ajoutez d'autres fichiers sources si nécessaire. Les fichiers objets résultants partagent le même nom de fichier mais utilisent l'extension de nom de fichier .o.

2. Transformez les fichiers objets en une bibliothèque statique (archive) à l'aide de l'outil ar du paquet binutils.

   $ ar rcs libfoo.a source_file.o...

   Le fichier libfoo.a est créé.

3. Utilisez la commande nm pour inspecter l'archive résultante :

   $ nm libfoo.a

4. Copiez le fichier de la bibliothèque statique dans le répertoire approprié.

5. Lors de l'édition de liens avec la bibliothèque, GCC reconnaît automatiquement, à partir de l'extension du nom de fichier .a, que la bibliothèque est une archive pour l'édition de liens statiques.

   $ gcc ... -lfoo...

Procédure

1. Créez un répertoire hellomake et allez dans ce répertoire :

   $ mkdir hellomake
   $ cd hellomake

2. Créez un fichier hello.c avec le contenu suivant :

   #include <stdio.h>
   
   int main(int argc, char *argv[]) {
     printf("Hello, World!\n");
     return 0;
   }

3. Créez un fichier Makefile avec le contenu suivant :

   CC=gcc
   CFLAGS=-c -Wall
   SOURCE=hello.c
   OBJ=$(SOURCE:.c=.o)
   EXE=hello
   
   all: $(SOURCE) $(EXE)
   
   $(EXE): $(OBJ)
           $(CC) $(OBJ) -o $@
   
   %.o: %.c
           $(CC) $(CFLAGS) $< -o $@
   
   clean:
           rm -rf $(OBJ) $(EXE)

   Important

   Les lignes de la recette du Makefile doivent commencer par le caractère tabulation ! Lorsque vous copiez le texte ci-dessus à partir de la documentation, le processus de copier-coller peut coller des espaces à la place des tabulations. Si cela se produit, corrigez le problème manuellement.

4. Exécuter make:

   $ make
   gcc -c -Wall hello.c -o hello.o
   gcc hello.o -o hello

   Cela crée un fichier exécutable hello.

5. Exécutez le fichier exécutable hello:

   $ ./hello
   Hello, World!

6. Exécutez la cible Makefile clean pour supprimer les fichiers créés :

   $ make clean
   rm -rf hello.o hello

Procédure

1. Lancez GDB attaché à l'application ou à la bibliothèque que vous souhaitez déboguer. GDB reconnaît automatiquement les informations de débogage manquantes et suggère une commande à exécuter.

   $ gdb -q /bin/ls
   Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
   (no debugging symbols found)...done.
   Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
   (gdb)

2. Quittez GDB : tapez q et confirmez avec Enter.

   (gdb) q

3. Exécutez la commande suggérée par GDB pour installer les paquets debuginfo requis :

   # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

   L'outil de gestion des paquets dnf fournit un résumé des changements, demande une confirmation et, une fois que vous avez confirmé, télécharge et installe tous les fichiers nécessaires.

4. Si GDB n'est pas en mesure de suggérer le paquet debuginfo, suivez la procédure décrite dans Obtenir manuellement les paquets debuginfo pour une application ou une bibliothèque.

Procédure

1. Rechercher le fichier exécutable de l'application ou de la bibliothèque.

   1. Utilisez la commande which pour trouver le fichier d'application.

      $ which less
      /usr/bin/less

   2. Utilisez la commande locate pour trouver le fichier de la bibliothèque.

      $ locate libz | grep so
      /usr/lib64/libz.so.1
      /usr/lib64/libz.so.1.2.11

      Si les raisons initiales du débogage comprennent des messages d'erreur, choisissez le résultat où le nom de fichier de la bibliothèque contient les mêmes nombres supplémentaires que ceux mentionnés dans les messages d'erreur. En cas de doute, essayez de suivre le reste de la procédure avec le résultat où le nom de fichier de la bibliothèque ne comporte pas de chiffres supplémentaires.

      Note

      La commande locate est fournie par le paquet mlocate. Pour l'installer et permettre son utilisation :

      # dnf install mlocate
      # updatedb

2. Rechercher le nom et la version du paquet qui a fourni le fichier :

   $ rpm -qf /usr/lib64/libz.so.1.2.7
   zlib-1.2.11-10.el8.x86_64

   La sortie fournit des détails sur le paquet installé au format name:epoch-version.release.architecture.

   Important

   Si cette étape ne donne aucun résultat, il n'est pas possible de déterminer quel paquet a fourni le fichier binaire. Plusieurs cas sont possibles :

   • Le fichier est installé à partir d'un paquet qui n'est pas connu des outils de gestion des paquets dans leur configuration current.
   • Le fichier est installé à partir d'un paquet téléchargé localement et installé manuellement. Dans ce cas, il est impossible de déterminer automatiquement un paquetage debuginfo approprié.
   • Vos outils de gestion des paquets sont mal configurés.
   • Le fichier n'est pas installé à partir d'un paquetage. Dans ce cas, il n'existe pas de paquetage debuginfo correspondant.

   Comme les étapes suivantes dépendent de celle-ci, vous devez résoudre cette situation ou interrompre la procédure. La description des étapes exactes du dépannage dépasse le cadre de cette procédure.

3. Installez les paquets debuginfo à l'aide de l'utilitaire debuginfo-install. Dans la commande, utilisez le nom du paquet et les autres détails que vous avez déterminés à l'étape précédente :

   # debuginfo-install zlib-1.2.11-10.el8.x86_64

1. Recherchez l'ID du processus (pid) à l'aide de la commande ps:

   $ ps -C program -o pid h
    pid

   Remplacez program par un nom de fichier ou un chemin d'accès au programme.

2. Attachez la GDB à ce processus :

   $ gdb -p pid

   Remplacer pid par un numéro d'identification de processus réel provenant de la sortie ps.

1. Utilisez la commande GDB shell pour exécuter la commande ps et trouver l'ID du processus du programme (pid) :

   (gdb) shell ps -C program -o pid h
    pid

   Remplacez program par un nom de fichier ou un chemin d'accès au programme.

2. Utilisez la commande attach pour attacher GDB au programme :

   (gdb) attacher pid

   Remplacer pid par un numéro d'identification de processus réel provenant de la sortie ps.

Procédure

1. Identifier les appels système à surveiller.

2. Lancez strace et joignez-le au programme.

   • Si le programme que vous voulez surveiller n'est pas en cours d'exécution, lancez strace et indiquez l'adresse program:

     $ strace -fvttTyy -s 256 -e trace=call program

   • Si le programme est déjà en cours d'exécution, recherchez son identifiant de processus (pid) et attachez-y strace:

     $ ps -C program
     (...)
     $ strace -fvttTyy -s 256 -e trace=call -ppid

   • Remplacez call par les appels système à afficher. Vous pouvez utiliser l'option -e trace=call plusieurs fois. Si elle n'est pas remplacée, strace affichera tous les types d'appels système. Voir la page de manuel strace(1) pour plus d'informations.
   • Si vous ne souhaitez pas suivre les processus ou les threads qui ont fait l'objet d'une bifurcation, n'utilisez pas l'option -f.

3. L'outil strace affiche les appels système effectués par l'application et leurs détails.

   Dans la plupart des cas, une application et ses bibliothèques effectuent un grand nombre d'appels et la sortie strace apparaît immédiatement, si aucun filtre pour les appels système n'est défini.

4. L'outil strace se termine lorsque le programme se termine.

   Pour mettre fin à la surveillance avant que le programme suivi ne se termine, appuyez sur Ctrl C.

   • Si strace a démarré le programme, celui-ci se termine en même temps que strace.
   • Si vous avez joint strace à un programme déjà en cours d'exécution, le programme se termine en même temps que strace.

5. Analyser la liste des appels système effectués par l'application.

   • Les problèmes d'accès ou de disponibilité des ressources sont signalés dans le journal par des appels renvoyant des erreurs.
   • Les valeurs transmises aux appels système et les modèles de séquences d'appels permettent de comprendre les causes du comportement de l'application.
   • Si l'application se bloque, les informations importantes se trouvent probablement à la fin du journal.
   • Le résultat contient beaucoup d'informations inutiles. Cependant, vous pouvez construire un filtre plus précis pour les appels système qui vous intéressent et répéter la procédure.

Procédure

1. Identifiez les bibliothèques et les fonctions qui vous intéressent, si possible.

2. Lancez ltrace et joignez-le au programme.

   • Si le programme que vous souhaitez surveiller n'est pas en cours d'exécution, lancez ltrace et indiquez program:

     $ ltrace -f -l library -e function program

   • Si le programme est déjà en cours d'exécution, recherchez son identifiant de processus (pid) et attachez-y ltrace:

     $ ps -C program
     (...)
     $ ltrace -f -l library -e function program -ppid

   • Utilisez les options -e, -f et -l pour filtrer les résultats :

     • Fournir les noms des fonctions à afficher sous la forme function. L'option -e function peut être utilisée plusieurs fois. Si elle est omise, ltrace affiche les appels à toutes les fonctions.
     • Au lieu de spécifier des fonctions, vous pouvez spécifier des bibliothèques entières avec l'option -l library pour spécifier des bibliothèques entières. Cette option se comporte de la même manière que l'option -e function cette option se comporte de la même manière que l'option
     • Si vous ne souhaitez pas suivre les processus ou les threads qui ont fait l'objet d'une bifurcation, n'utilisez pas l'option -f.

     Voir la page du manuel ltrace(1)_ pour plus d'informations.

3. ltrace affiche les appels à la bibliothèque effectués par l'application.

   Dans la plupart des cas, une application effectue un grand nombre d'appels et la sortie ltrace s'affiche immédiatement, si aucun filtre n'est défini.

4. ltrace se termine lorsque le programme se termine.

   Pour mettre fin à la surveillance avant que le programme suivi ne se termine, appuyez sur ctrl C.

   • Si ltrace a démarré le programme, celui-ci se termine en même temps que ltrace.
   • Si vous avez joint ltrace à un programme déjà en cours d'exécution, le programme se termine en même temps que ltrace.

5. Analyser la liste des appels à la bibliothèque effectués par l'application.

   • Si l'application se bloque, les informations importantes se trouvent probablement à la fin du journal.
   • Le résultat contient beaucoup d'informations inutiles. Cependant, vous pouvez construire un filtre plus précis et répéter la procédure.

Procédure

1. Recherchez l'ID du processus (pid) du processus que vous souhaitez surveiller :

   $ ps -aux

2. Exécutez SystemTap avec le script strace.stp:

   # stap /usr/share/systemtap/examples/process/strace.stp -x pid

   La valeur de pid est l'identifiant du processus.

   Le script est compilé dans un module du noyau, qui est ensuite chargé. Cela introduit un léger délai entre la saisie de la commande et l'obtention de la sortie.

3. Lorsque le processus effectue un appel système, le nom de l'appel et ses paramètres sont imprimés sur le terminal.
4. Le script se termine lorsque le processus se termine ou lorsque vous appuyez sur Ctrl C.

Procédure

1. Fixer le point d'inflexion :

   (gdb) catch syscall syscall-name

   La commande catch syscall définit un type spécial de point d'arrêt qui interrompt l'exécution lorsque le programme effectue un appel système.

   L'option syscall-name spécifie le nom de l'appel. Vous pouvez spécifier plusieurs points de capture pour différents appels système. L'omission de l'option syscall-name permet à GDB de s'arrêter sur n'importe quel appel système.

2. Lancer l'exécution du programme.

   • Si le programme n'a pas commencé à s'exécuter, démarrez-le :

     (gdb) r

   • Si l'exécution du programme est interrompue, reprenez-la :

     (gdb) c

3. GDB interrompt l'exécution après que le programme a exécuté un appel système spécifié.

Procédure

1. Fixer le point d'inflexion :

   (gdb) signal de capture signal-type

   La commande catch signal définit un type spécial de point d'arrêt qui interrompt l'exécution lorsqu'un signal est reçu par le programme. L'option signal-type spécifie le type de signal. Utilisez la valeur spéciale 'all' pour capturer tous les signaux.

2. Laissez le programme s'exécuter.

   • Si le programme n'a pas commencé à s'exécuter, démarrez-le :

     (gdb) r

   • Si l'exécution du programme est interrompue, reprenez-la :

     (gdb) c

3. GDB interrompt l'exécution après que le programme a reçu un signal spécifié.

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.

Procédure

1. Accédez au Red Hat Container Registry à l'aide de vos identifiants du portail client :

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. Extrayez l'image du conteneur dont vous avez besoin en exécutant la commande correspondante en tant que root :

   # podman pull registry.redhat.io/rhel9/gcc-toolset-12-toolchain

   Note

   Vous pouvez également configurer votre système pour travailler avec des conteneurs en tant qu'utilisateur non rooté. Pour plus de détails, voir Configuration de conteneurs sans racine.

3. Facultatif : Vérifiez que l'extraction a réussi en exécutant une commande qui répertorie toutes les images de conteneurs sur votre système local :

   # podman images

4. Exécuter un conteneur en lançant un shell bash à l'intérieur d'un conteneur :

   # podman run -it image_name /bin/bash

   L'option -i crée une session interactive ; sans cette option, l'interpréteur de commandes s'ouvre et se ferme instantanément.

   L'option -t ouvre une session de terminal ; sans cette option, vous ne pouvez rien saisir dans l'interpréteur de commandes.

Procédure

1. Accédez au Red Hat Container Registry à l'aide de vos identifiants du portail client :

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. Tirer l'image du conteneur en tant que root :

   # podman pull registry.redhat.io/rhel9/gcc-toolset-12-toolchain

3. Lancer l'image du conteneur avec un shell interactif en tant que root :

   # podman run -it registry.redhat.io/rhel9/gcc-toolset-12-toolchain /bin/bash

4. Exécutez les outils de la boîte à outils GCC comme prévu. Par exemple, pour vérifier la version du compilateur gcc, exécutez :

   bash-4.4$ gcc -v
   ...
   gcc version 12.1.1 20220628 (Red Hat 12.1.1-3) (GCC)

5. Pour lister tous les paquets fournis dans le conteneur, exécutez :

   bash-4.4$ rpm -qa