Ltrace

Fiche express
Domaine	Traçage des appels aux bibliothèques partagées
Commande	ltrace
Contexte	Diagnostic applicatif, debug de crash lié à une lib
Voir aussi	Strace (appels système)

ltrace trace les appels d'un processus aux fonctions des bibliothèques partagées (libc, libssl, libpthread…) qu'il utilise, avec leurs arguments et leur valeur de retour. C'est le complément de Strace : strace observe la frontière entre le processus et le noyau (appels système), ltrace observe la frontière entre le processus et ses bibliothèques (appels de fonctions). Un même symptôme peut nécessiter les deux outils selon qu'il se situe côté noyau ou côté bibliothèque.

Commandes de base

ltrace -p PID           # attacher ltrace à un process déjà en cours d'exécution
ltrace commande arg...  # lancer la commande et tracer ses appels de bibliothèques dès le départ
ltrace -f -p PID        # suivre aussi les processus fils (fork/clone)
ltrace -o fichier.log commande  # rediriger la trace vers un fichier plutôt que stderr

Résumé statistique (-c)

Comme strace -c, l'option -c n'affiche pas chaque appel individuellement mais un tableau récapitulatif en fin d'exécution : nombre d'appels par fonction, temps cumulé et pourcentage du temps total passé dans chaque fonction. Très utile pour repérer rapidement quelle fonction de bibliothèque consomme le plus d'appels ou de temps, sans noyer l'analyse dans des milliers de lignes.

ltrace -c commande

Filtrer sur une fonction (-e)

L'option -e restreint la trace à une ou plusieurs fonctions précises, ce qui évite le bruit des appels non pertinents pour le problème en cours.

ltrace -e malloc+free -p PID   # ne tracer que les allocations/libérations mémoire
ltrace -e 'ssl_*' commande     # ne tracer que les fonctions dont le nom commence par ssl_

Cas d'usage typique

• Comprendre pourquoi une application appelle une bibliothèque de façon inattendue (ex. une fonction de résolution DNS appelée en boucle, une lib de compression sollicitée alors qu'elle ne devrait pas l'être).
• Débogage d'un crash ou d'un comportement anormal lié à une bibliothèque tierce, quand on veut voir les derniers arguments passés avant le plantage.
• Diagnostic de lenteur applicative quand le goulot d'étranglement est suspecté côté bibliothèque plutôt que côté appel système (dans ce dernier cas, préférer Strace).

Limites connues

ltrace introduit un overhead important sur le process tracé, nettement plus perceptible que celui de strace, ce qui peut suffire à masquer ou déformer un problème de timing (à vérifier). Le traçage devient également imprécis, voire inopérant, avec du code optimisé ou lié statiquement : ltrace repère les appels de fonctions via la PLT (Procedure Linkage Table) utilisée par le lien dynamique, et un binaire statiquement lié ne passe pas par ce mécanisme (à vérifier).

Voir aussi

• Strace — trace les appels système (noyau), à ne pas confondre avec les appels de bibliothèques tracés par ltrace