Intéressant à corriger les erreurs de bibliothèque et les bogues que vous observez lors de l'installation d'un nouveau programme sympa sur Linux ? Consultez cet article qui montre comment utiliser ltrace, vous armant de l'outil nécessaire pour déboguer les appels de bibliothèque.
Qu'est-ce qu'une bibliothèque?
La plupart des gens connaissent les fichiers .dll/.DLL (Dynamic Link Libraries) dans Windows. L'équivalent Linux est un fichier .so, un objet partagé, souvent appelé simplement bibliothèque.
Une bibliothèque peut être utilisée par une application permettant à ce programme d'utiliser des fonctionnalités en dehors de son code de programme. Par exemple, un serveur Web peut souhaiter utiliser une bibliothèque d'E/S de disque écrite par le fournisseur du système d'exploitation ou un autre tiers. C'est un moyen de partager des biens et des intérêts communs dans la plupart, sinon tous les systèmes d'exploitation.
Les bibliothèques peuvent être chargées dynamiquement au moment de l'exécution (lorsque le programme appelant démarre, par exemple), ou elles peut être compilé dans une application/un binaire cible. Ils seront donc toujours chargés (qu'ils soient utilisés ou non), dans le cadre et à chaque démarrage de l'application qui les a compilés/intégrés.
Pour en savoir plus sur les bibliothèques, leurs dépendances et l'outil ldd, vous pouvez lire comment utiliser les dépendances d'objets partagés sous Linux. L'outil ldd est un autre outil pratique à avoir dans toute boîte à outils utilisateur Linux plus avancée.
qu'est-ce que ltrace ?
Il existe divers utilitaires de traçage sous Linux, comme strace pour le traçage des appels et des signaux système et le traceroute pour tracer le routage du réseau. L'utilitaire/outil ltrace trace tous les appels de bibliothèque.
Publicité
Si vous avez lu notre travail avec les dépendances d'objets partagés (bibliothèque) dans l'article Linux (lié ci-dessus), vous aurez déjà vu comment vous pouvez trouver à quelles bibliothèques un binaire particulier est lié en utilisant l'outil ldd. L'objectif et la fonctionnalité d'ltrace sont quelque peu différents ; très conforme à strace, la commande ltrace trace tous les appels de bibliothèque qu'un programme particulier effectue pendant son exécution.
Comme pour strace, nous pouvons démarrer un programme sous(pensez-y comme une hiérarchie) ltrace. Nous spécifions simplement le programme que ltrace doit démarrer comme première option de ltrace, et ltrace démarrera ce programme pour nous et commencera immédiatement (à un niveau supérieur) à suivre tous les appels à toutes les bibliothèques (système d'exploitation ou tierces installées).< /p>
Il le fait en interceptant et en enregistrant les appels de bibliothèque dynamiques effectués par le programme en cours d'exécution. Il suivra également tous les signaux envoyés au programme en cours d'exécution, très similaire à strace (et, si vous le souhaitez, cette fonctionnalité peut être désactivée en spécifiant l'option -b ou l'option –no-signals équivalente à ltrace).
Notez que le terme dynamique est d'une importance significative ici ; ltrace tracera les appels aux bibliothèques externes (sous la forme de fichiers .so ou .a), c'est-à-dire les bibliothèques qui ne sont pas directement compilées dans un programme ; Bibliothèques dynamiques. Ainsi, si vous avez un binaire avec des bibliothèques statiquement (compilées), ltrace ne pourra pas voir/tracer de tels appels internes.
Installation < i>ltrace
Pour installer ltrace sur votre distribution Linux basée sur Debian/Apt (comme Ubuntu et Mint), exécutez la commande suivante dans votre terminal :
sudo apt install ltrace
Publicité
Pour installer ltrace sur votre distribution Linux basée sur RedHat/Yum (comme RHEL, Centos et Fedora), exécutez la commande suivante dans votre terminal :
sudo yum install ltrace
Utilisation de ltrace
Configurons un petit environnement de test :
sudo apt install tar xz-utils mkdir ~/workspace && cd ~/workspace touch a b c
Ici, nous avons installé tar et xz en installant xz-utils (vous pouvez utiliser sudo yum install tar xz à la place si vous utilisez Centos/RHEL/Fedora). Ensuite, nous avons créé un répertoire ~/workspace et avons sauté dedans. Nous avons ensuite créé trois fichiers vides à l'aide de la commande tactile, à savoir les fichiers a, b et c.
Commençons par compresser nos trois fichiers dans un (tar combiné et xzcompressé) archive.tar.xz, tout en exécutant la même chose sous ltrace, et en observant la sortie de ltrace :
Nous ne voyons qu'une petite quantité de sortie. Nous pouvons voir que notre programme s'est terminé avec succès (le fichier archive a été créé), c'est-à-dire l'état 0 : un code de sortie de 0 signifie toujours le succès sous Linux (bien que le programme ait besoin d'avoir des codes de sortie correctement implémentés).
Ce n'est pas très utile pour l'instant. Raisonner quelques secondes sur le fonctionnement du goudron ici révélera rapidement notre prochaine approche. Le lecteur avide a peut-être également compris que la commande tar en interne appellerait la commande xz. L'option –xz passée à notre ligne de commande tar garantira que le programme xz est utilisé pour la compression.
Le processus secondaire (ou le troisième dans la hiérarchie globale) à savoir xz (hiérarchie : ltrace > tar > xz) sera démarré par tar si nécessaire. En tant que tel, nous devons tracer les processus fils du programme exécuté sous ltrace, c'est-à-dire tar. Nous pouvons le faire en spécifiant l'option suivante (-f) pour ltrace :
ltrace -f tar – hcf –xz archive.tar.xz * Publicité
Notez qu'il est important de spécifier l'option -f directement derrière ltrace et pas plus tard dans la ligne de commande après tar par exemple. La raison en est que nous voulons spécifier cette option à ltrace et non à la commande tar. Toutes les options après la commande tar sont des options spécifiques à tar alors que -f est une option spécifique à ltrace.
La sortie est un peu plus intéressante. Nous n'observons pas encore d'appels de bibliothèque (de quelque forme que ce soit), mais nous voyons au moins que deux sous-processus sont fork (notez exec()) et que les deux sous-processus se terminent avec le statut 0. Pratique et tout va bien.
Alors, où sont nos appels à la bibliothèque ? En vérifiant tar et xz (les deux programmes qui seront utilisés par la commande pour créer le fichier archive) avec ldd, on se rend vite compte que la plupart des bibliothèques que les deux programmes utilisent sont des bibliothèques système :
où est tar où est xz ldd /bin/tar ldd /usr/bin/xz
Nous devons donc aller plus loin et activer le traçage des appels à la bibliothèque système en spécifiant l'option -S à ltrace. Cette option est désactivée/désactivée par défaut car la sortie deviendrait un peu verbeuse, et on suppose probablement que les bibliothèques système sont généralement beaucoup plus stables et, en tant que telles, n'ont pas besoin d'être tracées pour commencer. Jetons un coup d'œil.
ltrace -fS tar -hcf –xz archive.tar.xz *
Ou, à des fins de test :
ltrace -fS tar -hcf –xz archive.tar.xz * 2>&1 | head -n10 ltrace -fS tar -hcf –xz archive.tar.xz * 2>&1 | queue -n10
Comme la sortie était importante, nous avons dû capturer les dix premières et dernières lignes à l'aide d'une commande tête et queue. Pour pouvoir utiliser ces commandes, nous avons dû rediriger stderr vers stdout en utilisant la redirection 2>&1 car ltrace rapportera par défaut sur stderr. Si vous souhaitez en savoir plus sur la redirection, consultez Bash Automation and Scripting Basics (Partie 3).
Publicité
Maintenant que nous avons ajouté l'option -S, nous pouvons voir toutes les bibliothèques accessibles. Par exemple, nous voyons l'accès à /etc/ld.so.preload. La sortie est séquentielle (de haut en bas), donc s'il y a d'autres événements (sous-traitement en cours de bifurcation, etc.) entre les deux, ceux-ci seront affichés en ligne au moment où ils se produisent. Nous pourrions également ajouter l'option -t pour la sortie temporelle :
Conclusion
Dans cet article, nous avons présenté et discuté le programme polyvalent ltrace, qui est un excellent outil permettant de tracer tous les appels de bibliothèque dynamiques effectués par un programme donné. Nous avons installé ltrace, mis en place un environnement de test et exécuté quelques commandes ltrace avec les options les plus couramment utilisées.