PTT : outil de trace pour la NPTL

Posté par  . Modéré par Mouns.
Étiquettes :
0
24
avr.
2006
Linux
La NPTL (Native POSIX Thread Library) est la bibliothèque de threads [en français, processus légers] incluse en standard dans la glibc. Le support de l'ancienne bibliothèque LinuxThreads n'est maintenant plus assuré.
Le processus de débogage d'une application multi-threadée utilisant la NPTL est souvent complexe : bugs non reproductibles, dépendants de la charge du système et du nombre de CPUs, emploi de débogueurs modifiant la dynamique de l'application et donc son comportement...

PTT (POSIX Thread Trace Toolkit) est un outil distribué sous licence LGPL ayant pour but de faciliter l'analyse et le débogage d'applications multithreadées utilisant la NPTL. Il permet de tracer les évènements internes de la NPTL (entrées/sorties des routines, prises et relâchements de verrous...) tout en ayant un impact très faible sur les performances.
PTT est fourni sous la forme d'un patch pour la glibc et d'outils de récupération et d'analyse des traces. Son utilisation ne nécessite pas les droits de super-utilisateur et n'altère en rien le noyau ou les librairies du système.

La nouvelle version 0.10.0 de cet outil est disponible sur SourceForge. Les processus d'installation et d'utilisation ont été grandement simplifiés. PTT fonctionne sur plusieurs types d'architectures 32 et 64 bits (en particulier ia32, ia64 et PowerPC).

Une application multithreadée peut être tracée sans qu'une recompilation ne soit nécessaire. Un fichier binaire contenant l'enregistrement des évènements de la NPTL est construit pendant le processus de traçage. Une fois l'application terminée, ce fichier peut être traduit sous la forme d'un fichier texte directement lisible, d'un fichier facilement "parsable" par des outils classiques (grep, awk...) ou d'un fichier permettant une visualisation sous forme graphique par l'intermédiaire du logiciel Pajé.

PTT possède les caractéristiques suivantes :
  • permet à plusieurs personnes de tracer différents programmes en même temps;
  • supporte de gros volumes de traces pour des applications s'exécutant pendant de longues durées (heures, jours) avant qu'un problème ne survienne;
  • sélection dynamique du niveau de trace
  • filtrage des traces suivant plusieurs critères (types d'objets, d'évènements, dates...);
  • supporte les applications effectuant des "fork" afin de tracer les processus fils;
  • gère les terminaisons anormales des applications (interruptions, crash...);
  • préserve la conformité avec la norme POSIX.

Le patch de la glibc fourni avec PTT:
  • insère les points de trace dans les routines de la NPTL;
  • fournit un module permettant de récolter ces traces;
  • modifie les fichiers de configuration de la glibc, permettant ainsi de construire une version de la glibc sans aucune modification, et la version ajoutant les points de trace (./configure --with-ptt).

Il est également prévu de fournir des outils d'analyse statistique et de performance des applications tracées.

Aller plus loin

  • # Bravo

    Posté par  . Évalué à 2.

    Continuez. C'est un outil très efficace!
    • [^] # Re: Bravo

      Posté par  . Évalué à 10.

      Merci !

      Pour ce qui est de "continuez", les outils d'analyse dont il est question à la fin de l'article s'appuyeront sur le fichier de trace généré par PTT pour extraire des informations quantitatives relatives à la contention des threads (temps d'attente global, par thread, impact des différents mutex, semaphores, barrières, conditions) et ainsi mieux comprendre le fonctionnement de l'application, et la manière dont elle peut être optimisée. Toutes les idées sont les bienvenues à ce propos.

      Nous espérons également pouvoir convaincre des distributions d'intégrer PTT. Le travail d'intégration de PTT dans la glibc a eu pour but de simplifier au maximum l'effort des mainteneurs potentiels de distributions.

      Nous pensons que tels outils de trace sont nécessaires afin d'améliorer la qualité de Linux en répondant à des besoins de nature "industrielle" : un professionnel peut accepter qu'il existe des problèmes dans le système qu'il utilise à condition qu'il ait le moyen de les identifier immédiatement et de les corriger lorsqu'ils se produisent. C'est justement l'objectif d'un outil comme PTT.
  • # Pajé

    Posté par  (Mastodon) . Évalué à 5.

    La page officielle de Pajé est sur la forge d'ObjectWeb maintenant :
    http://forge.objectweb.org/projects/paje/

    Ce projet est toujours très actif et très utilisé mais son principal point faible est qu'il est développé en Objective C.
    • [^] # Re: Pajé

      Posté par  (site web personnel) . Évalué à 1.

      Oui, j'ai essayé Pajé à l'occasion. C'est une horreur à compiler (y'a pas de paquet disponible sous Mandriva), et l'interface est vraiment pas agréable. La même chose en Gtk2 serait beaucoup plus simple à compiler et beaucoup plus agréable à utiliser.
      • [^] # Re: Pajé

        Posté par  (site web personnel) . Évalué à 5.

        Sous Debian, j'ai installé les paquets « gnustep gnustep-make gnustep-devel libgnustep-gui0.10-dev (qui installent plein de trucs dont gobjc) (rien que ça). Ensuite, commandes pour compiler et installer :

        . /usr/share/GNUstep/Makefiles/GNUstep.sh
        make
        sudo make install


        Enfin, pour le lancer : « openapp Pake.app ».

        Bon, le problème est la détection des dépendences un peu foireuse et que nul part il y a écrit : il faut évaluer /usr/share/GNUstep/Makefiles/GNUstep.sh dans votre shell :-/

        Houlà, c'est moche, ça me rappelle ce bon vieux WindowMake ... rah là là, c'est pas gagné GNUstep ...

        Haypo
        • [^] # Re: Pajé

          Posté par  . Évalué à 2.

          pourquoi pas un simple :
          apt-get install paje.app

          On le trouve dans unstable/testing/stable (même si les versions sont un peu vieilles pour testing/stable.
          Et sinon, recompiler à partir des sources du paquet Debian permet de profiter du travail d'adaptation du mainteneur pour Debian...

          vdanjean@cayuga:~$ apt-cache search paje
          paje.app - generic visualization tool (Gantt chart and more)
          vdanjean@cayuga:~$ apt-cache policy paje.app
          paje.app:
          Installé : 1.4.0-1
          Candidat : 1.4.0-1
          Table de version :
          *** 1.4.0-1 0
          990 ftp://ftp.debian.org unstable/main Packages
          100 /var/lib/dpkg/status
          1.3.2-4 0
          500 ftp://ftp.debian.org testing/main Packages
          1.3.2-3 0
          500 http://ftp.debian.org stable/main Packages
        • [^] # Re: Pajé

          Posté par  (site web personnel) . Évalué à 3.

          pour la compilation, sourcer GNUstep.sh est (encore) nécessaire, mais pour l'exécution normalement non... en tout cas avec une version récente de gnustep.

          Quand au look, ben hein.. faut voir avec camaelon non ? au pire, utiliser preferences.app pour virer le gris sombre par un gris plus léger :)

          'fin bon.
    • [^] # Re: Pajé

      Posté par  (site web personnel) . Évalué à 2.

      Ce projet est toujours très actif et très utilisé mais son principal point faible est qu'il est développé en Objective C.


      C'est aussi son point fort à mon humble avis. Son point faible c'est que le toolkit GNUstep est pour l'instant à la traîne par rapport à GTK2 ou Cocoa. Mais bientôt j'intégrerais l'équipe d'étoilé et ... ... TUT TUT TUT.... Haaaaaaaaaa ! Merde il est quelle heure ! chui en retard pour le boulot ! Il était pourtant bien ce rêve
      • [^] # Re: Pajé

        Posté par  (site web personnel) . Évalué à 5.

        « GNUstep est pour l'instant à la traîne par rapport à GTK2 ou Cocoa » : ben franchement, je trouve qu'il est mort ce projet. On dirait qu'ils n'y ont pas touché depuis 1990 (bon, disons depuis que j'ai remplacé WindowMaker par XFCE4 ou Gnome2, y'a longtemps donc).

        Haypo
        • [^] # Re: Pajé

          Posté par  (site web personnel) . Évalué à 4.

          En effet, mais c'est dommage. Si on regarde au niveau du design du langage, c'est de loin le meilleur des descendants du C.

          D'autre part, windows maker fait partie du projet GNUstep mais n'ai pas programmé Obj C (c'est du pure C) et donc ne s'appuie pas sur le toolkit GNUSTEP.

          Ce qui manque pour moi à ce toolkit c'est :
          1) plus de programmeurs ;)
          2) un bureau attractif, un truc joli pas tout gris quoi (etoilé, étoilé étoilé !!!!!! [2] )
          3) une compatibilité niveau source avec Cocoa (et ça c'est dur parce que c'était pas le but du projet initial [...blablablabla...] openstep [...blablablabla...], que c'est dur à entendre par certains "lead developper" à un moment où le projet arrive au terme de ce qui était fixé au départ et, enfin, qu'il n'ont pas envie d'être encore en train d'être à faire de la réimplémentation sans la prise de decision qui fait plaisir... Je les comprends ... Mais y'a qu'a voir les sources de GNUmail [3] pour voir que c'est bien prise de tête de supporter les 2 architectures à coup de #ifdef )

          [1] => http://gnustep.org/developers/whoiswho.html et http://www.etoile-project.org/etoile/mediawiki/index.php?tit(...)

          [2] => http://www.etoile-project.org/etoile/mediawiki/index.php?tit(...)

          [3] => http://www.collaboration-world.com/gnumail/

          Ps: Un jour j'y participerais, un jour ...
        • [^] # Re: Pajé

          Posté par  (site web personnel) . Évalué à 5.

          >On dirait qu'ils n'y ont pas touché depuis 1990

          Tu as regardé les ChangeLog et la quantité de code ?
          http://svn.gna.org/viewcvs/gnustep/

          Moi je dirais pas qu'il est mort ( et loin de là )

          Par contre je dirais qu'il y a beaucoup trop de code même pour les 30 développeurs GNUstep ( ce qui est beaucoup même comparé à QT ou gtk/Glib) .....

          Je pense que le code GNUstep est dans bien des points largement supèrieur à QT ou Glib/GTK.

          Le problème c'est que les développeurs de Framework / Libraries ne développent pas d'applications ......

          Et sans applications ... ça reste juste une belle implementation de belles spécifications
          • [^] # Re: Pajé

            Posté par  (site web personnel) . Évalué à 3.

            Oui, GNUstep avance, tranquillement... ceci dit, 30 développeurs GNUstep ... oui, plus ou moins; mais quand j'ai dit ça au fosdem (je subodore que ce chiffre vient de là, me trompes-je ?), après coup j'ai réalisé que je m'était vraiment mal exprimé (le fameux esprit d'escalier!) -- je ne voulais pas dire qu'il y a 30 devs qui bossent sur le repository gnustep aujourd'hui, mais plutôt donner un ordre d'idée de la "communauté gnustep", eg combien de devs plus ou moins actifs...

            Malheureusement, tous ne travaillent pas sur les frameworks eux-mêmes.. et en plus, pour ceux qui bossent dessus, on est loin d'avoir tout le monde committant en coeur tous les soirs ;-) (dommage !)

            Si c'était le cas, punaise, ça ferait longtemps que tout serait nickel :D

            Sur gnustep -core lui même, il y a plutôt un coeur de 4-6 développeurs assez réguliers, mais c'est tout... (et encore, -gui est le mal aimé). Après il y a des gens qui participent plus épisodiquements, puis d'autres qui bossent sur des applis, etc.

            Je sais pas pour Gtk, mais à mon avis il y a un tout petit peu plus de monde qui bosse sur Qt que sur GNUstep ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.