Journal Comment "tracer" une application ?

Posté par  .
Étiquettes : aucune
0
19
oct.
2007
Bonjour à toi journal !

Je cherche actuellement à optimiser _et_ à surveiller le comportement d'une application en C un peu complexe.
Par surveiller, je veux dire "est-ce que l'application a bien exécuté cette fonction ?", "quel est le résultat de cette opération ?".

Pour la surveillance, rien de plus simple que de mettre des traces dans le logiciel, à coup de "fprintf(stderr, "Trace gna gna gna\n");", on se rend compte très vite du comportement de la bête. On peut même post-processer les traces sur des exécutions "longues".

On peut pousser plus loin la logique et essayer d'optimiser l'application à partir de ces informations. Par exemple, on peut ajouter un "fprintf(stderr, "%ld trace \n", get_cycle());" pour ajouter un élément "timing" à la trace.
Mais les mesures de temps sont forcément imprécises (elles dépendent des tampons sur le flux, etc...).

A partir de là, on pourrait penser à un thread qui ne servirait qu'à collecter les informations ou alors à une zone de mémoire partagée entre l'application et un collecteur de données. Mais ça demandent un investissement et un temps de développement plus important que de placer des "fprintf" dans un code.

Notez que le passage d'un profileur type gprof/sprof n'est pas toujours d'un grand secours quand le code contient de grosses fonctions, des inlines et des macros. :)

Je suis donc à la recherche d'un outil qui permettent "d'instrumenter" le code (par exemple en insérant des appels à des macros dans le code) puis de le tracer avec des mesures de temps, a l'exécution.

J'ai déjà utiliser le Posix Thread Trace Toolkit [1] et c'est plutôt pas mal. Malheureusement les points de trace sont limités aux fonctions de manipulation de thread. (A ma connaissance, il n'est pas possible de spécifier des points de trace arbitraires dans le code d'une application).

Pour un peu plus préciser ce qui me ferait rêver, j'ai trouvé une interface "TimeDoctor" [2] qui affiche des évènements. On pourrait imaginer que chaque ligne constitue un thread de l'application, et que chaque évènements soient liés à une activité particulière du thread (appel d'une macro dans le thread).

Avez-vous des pistes ?

[1] : http://nptltracetool.sourceforge.net/
[2] : http://sourceforge.net/project/screenshots.php?group_id=1747(...)

  • # strace ?

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

    Je ne suis pas sur qu'il fasse ce dont tu as besoin, mais pour voir ce qui se passe, j'utilisais strace http://sourceforge.net/projects/strace/

    Par contre, je crois qu'il se limite aux appels système et je ne sais plus s'il donne un timing.
    Mais il m'a sauvé la vie plus d'une fois :)

    Ah oui et pour déboguer, je me méfie des printf, dans certains cas ça change le comportement du programme au point de ne plus voir les bugs, ou en amener d'autres, surtout dans un environnement multithread ou le timing joue beaucoup.

  • # Valgrind

    Posté par  . Évalué à 3.

    Il y a aussi valgrind et les outils qui tournent autour, qui te premettent de profiler l'application (temps passé dans une fonction, nombre d'appels, ...) Bon par contre si tu veux connaitre le nombre de passage dans une boucle, je ne crois pas que ce soit possible (à moins de mettre la boucle dans une fonction toute seule)
    http://valgrind.org/
    Bon ça fait un moment que je ne l'ai plus utilisé, faudra que tu lises un peu la doc, parce que je ne sais plus comment faire.

    • [^] # Re: Valgrind

      Posté par  . Évalué à 2.

      Hum, je me rend compte que j'avais passé une ligne dans ton journal, qui disait que ce genre d'outil n'allait pas. Désolé.

  • # Glibc + Gcc

    Posté par  . Évalué à 5.

    J'utilise actuellement çà pour suivre ce que fait une application complexe : çà permet d'avoir une bonne idée de la localisation d'un plantage lorsqu'on n'avait pas prévu de lancer valgrind ou gdb avant, surtout quand l'application ne s'y prête pas vraiment (genre un CGI en C).

    Code d'exemple + screen de ce que çà peut donner :
    http://athanatos.free.fr/finstrument-functions.png
    http://athanatos.free.fr/drizzt.c

  • # gprof

    Posté par  . Évalué à 7.

    Peut être que ça peut t'aider ...

    http://www.daimi.au.dk/~sandmann/sysprof/

    • [^] # Re: gprof

      Posté par  . Évalué à 1.

      Je pertinente !
      J'ai immédiatement pensé à lui en lisant le journal, je pense que ca correspond en grande partie à ce que tu recherches.

  • # GMemLogger

    Posté par  . Évalué à 1.

    Bonjour,

    J'avais eu le meme genre de besoin autrefois. Du coup, j'avais commis cet outil : GMemLogger.
    Il est aujourd'hui a l'abandon. Mais si ca correspond a ton besoin, tu pourras le completer. C'est une bonne base pour demarrer.

    http://www.nongnu.org/gmemlogger/gmemlogger.fr.html

    Yves

  • # Gcov/Gdb ?

    Posté par  . Évalué à 3.

    "est-ce que l'application a bien exécuté cette fonction ?"
    GCov, pour les tests de couverture de code,

    "quel est le résultat de cette opération ?".
    GDB non ?

  • # "Profiling Desktop Applications"

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

    Un script intéressant de Federico Mena-Quintero.

    http://www.gnome.org/~federico/news-2006-03.html#login-time-(...)

    La vidéo de la conférence :
    http://archive.fosdem.org/2007/schedule/events/profiling_des(...)

  • # 2 choses différentes

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

    Je crois que tu demandes 2 choses différentes, entre la surveillance d'un appli et son optimisation.

    coté optimisation, gprof + les outils de code coverage donne une bonne idée des lignes de code qui prennent du temps.

    Oprofile permet d'aller encore plus loin.

    valgrind permet aussi de faire des statistiques sur l'utilisation du cache.

    "La première sécurité est la liberté"

  • # Profiteur

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

    J'en profite pour dire que débugger à grands coups de printf est une très mauvaise idée, surtout si tu n'utilises pas uniquement des entiers dans ton programme.
    En deux mots, la raison est que les flottants n'ont pas la même précision dans les registres de ton proco et dans la mémoire. Printf rajoute des transferts CPU<->RAM et ainsi génère des Heisenbug.

    Je sais pas ce que tu programmes, mais tu pourrais songer utiliser des langages de plus haut niveau, objets ou fonctionnels, pour automatiser les traces, et profiter des compilateurs sioux des langages aussi sioux qui utilisent des représentations constantes des données.

    Scheme avec une macro LAMBDA pour tracer les appels, Haskell avec une monade de log pour les memes raisons...

    Bref, c'est pas specialement a toi que je dis ca, mais aussi aux autres moules : laissez tomber C sauf si vous faites drivers. Utilisez des langages fonctionels, ca fait aussi bien, et plus agréablement.

Suivre le flux des commentaires

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