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
- La page de PTT (11 clics)
- Téléchargement de PTT (8 clics)
- NPTL (Wikipedia) (2 clics)
# Bravo
Posté par v_atekor . Évalué à 2.
[^] # Re: Bravo
Posté par Guillaume Duranceau . Évalué à 10.
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 rewind (Mastodon) . Évalué à 5.
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 Thomas Petazzoni (site web personnel) . Évalué à 1.
[^] # Re: Pajé
Posté par Victor STINNER (site web personnel) . Évalué à 5.
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 Vincent Danjean . Évalué à 2.
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 Nicolas Roard (site web personnel) . Évalué à 3.
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 FReEDoM (site web personnel) . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 5.
Haypo
[^] # Re: Pajé
Posté par FReEDoM (site web personnel) . Évalué à 4.
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 FReEDoM (site web personnel) . Évalué à 3.
"mais n'ai pas programmé" : bien ouej :) la grande classe...
[^] # Re: Pajé
Posté par oops (site web personnel) . Évalué à 5.
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 Nicolas Roard (site web personnel) . Évalué à 3.
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.