Valgrind 2.2.0

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
1
sept.
2004
Technologie
Une nouvelle version du compagnon du développeur sous Linux vient de sortir. Il gère maintenant le « profiling », la vérification mémoire stricte. L'optimisation de l'utilisation du cache est maintenant possible, même pour les applications multimédia.

Il permet de détecter les erreurs au moment de l'exécution (fuites, non-initialisation, dépassement, écrasement) et de vérifier l'usage du cache (Cachegrind). Il intègre maintenant un nouvel outil, Massif, qui permet de dessiner en Postscript des graphiques de votre utilisation du tas (en C/C++, aussi appelé « heap »).

Le support de presque toutes les instructions multimédia, MMX, SSE, SSE2, SSE3 lui permet maintenant d'aider à optimiser les applications plus orientées « utilisateurs » (jeux, lecteurs son et vidéo, etc.). Il ne manque plus que 3DNow.

C'est un bon outil pour déboguer et améliorer vos applications Linux (NdM : sur architecture x86 uniquement) : les outils commerciaux « équivalents » sont loin d'avoir toutes ces fonctionnalités et sont très chers.

À noter : il est possible de « valgrinder » des applications Windows, sous GNU/Linux, avec une version spéciale de WINE...

Aller plus loin

  • # Précisions

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

    Je précise un peu :
    plusieurs outils (plugins) sont dans valgrind :

    2 decteurs d'erreur memooire
    1 detecteur d'erreur de thread
    1 profiler de cache
    1 profiler e tas

    Ce qu'il aide notamment a détecter :

    Lecture/écriture en mémoire apres libération.
    Lecture/écriture en dépassant une zone mallocée .
    Lecture/écriture au mauvais endroits dans le tas.
    fuites mémoire - pointeurs non libérés
    Variables non-initialisées utilisées et utilisation d'adresse mémoire non-adresssable dans les appels systemes.
    Mauvaise utilisation d'une paire malloc/new/new [] et free/delete/delete [] (comme new[] puis delete au lieu de delete[])
    Mauvaise utilisation des pthreads (POSIX)
    Les "cache hits" par fonctions.

    Ce qui est nouveau dans cette version c'est Massif et le support SSE2/SSE3. Le reste est amélioré, débogué. (on pouvait "profiler" et verifier la memoire avant.)

    Du coup DIOTA, un concurrent, qui devait remplacer valgrind sur le multimédia et l'optimisation en prends pour son grade.
    (http://www.elis.rug.ac.be/~ronsse/diota/(...))

  • # citation

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

    les outils commerciaux « équivalents » sont loin d'avoir toutes ces fonctionnalités et sont très chers.

    Ce qui me fait dire : "Valgrind, il y'a moins bien, mais c'est plus cher"

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: citation

      Posté par  . Évalué à 2.

      Valgrind est GPL : c'est autant un logiciel commercial qu'un autre.

      • [^] # Re: citation

        Posté par  . Évalué à 4.

        Ce n'est pas parce que Stallman a précisé qu'un logiciel sous GPL pouvait être commercialisé que tous les logiciels sous GPL sont commercialisés! La preuve :Valgrind ne l'est pas et ce n'est donc pas un logiciel commercial...

        • [^] # Re: citation

          Posté par  . Évalué à -4.

          La question n'est pas de savoir ce qu'untel a dit ou n'a pas dit. La question n'est pas de savoir si tel logiciel est commercialisé mais s'il peut l'etre.

          Les faits sont simples : je peux trés bien, si je le désire, commercialiser Valgrind. Il est donc parfaitement faux de dire que ce logiciel n'est pas commercial. Il peut l'etre sans problème.

          Mon exemple parait hypothetique ? Remplacez le "je" par le nom d'une distribution GNU/Linux commerciale.

          • [^] # Re: citation

            Posté par  . Évalué à 4.

            Il est donc parfaitement faux de dire que ce logiciel n'est pas commercial. Il peut l'etre sans problème.

            il n'est donc pas commercial mais commercialisable . c'est très différent.

            • [^] # Soyons concrets.

              Posté par  . Évalué à -2.

              Valgrind est commercial : dès à présent vous pouvez commander chez moi votre copie de valgrind, à 50 euros pièces. Il n'est plus seulement commercialisable, ça y est, dès aujourd'hui il est commercialisé.

              J'ai lu par ailleurs que Redhat l'incluait dans Fedora. J'imagine que RedHat va sans doute aussi l'inclure dans son propre produit commercial : et donc que Valgrind, comme tout les autres logiciels GPL vendus par RedHat est commercial.



              Conclusion : opposer logiciel libre à logiciel commercial est parfaitement insensé.

              • [^] # Re: Soyons concrets.

                Posté par  . Évalué à 1.

                Mmm... tu as un numéro de SIRET ? 8-) 'tention... lol

  • # Profiling et autres outils

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

    Il existe une version de gprof compatible valgrind :
    http://www.goop.org/~jeremy/valgrind/vgprof.html(...)

    les patches du meme monsieur sont aussi interressants :
    http://www.goop.org/~jeremy/valgrind/(...)

    Tant qu'on est dans les patches, un pour GDB 6.0 pour utiliser valgrind :
    http://www.atomice.com/gdb-valgrind.html(...)

    Au passage, puisqu'on cite gprof, Un nouvel outil de profiling sous Linux, avec un surcout minimal (1-3%) et sans recompilation et multi-architecture :

    http://oprofile.sourceforge.net/about/(...)
    (un certain contributeur très actif de xvid qui m'a mis sur la piste de celui-ci dans les forums, merci a lui)

    (Si vous avez d'autres outils d'aide au developppement aussi indispensables...)

  • # sur PPC aussi...

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

    grâce à Paul Mackerras (un des développeurs kernel ppc):

    http://ozlabs.org/~paulus/valgrind-2.2.0-ppc.tar.bz2(...)

    • [^] # Re: sur PPC aussi...

      Posté par  . Évalué à 3.

      Ca marche pour débugger du noyau valgrind?

      valgrind insmod monmodule.ko ?

      • [^] # Re: sur PPC aussi...

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

        non...mais sur 2.6 tu as les oopses avec backtrace dans dmesg.

        • [^] # Re: sur PPC aussi...

          Posté par  . Évalué à 4.

          ah oui ca peut aider en effet. le probleme c'est que je bosse en 2.4, et c'est apperement pas pret de migrer :(

          Apres, tous les types de bugs repérés par valgrind sont aussi valables dans le noyau, et peuvent générer des oops inexplicables bien plus loin de la meme maniere que tu peut avoir des segfault qui apparaissent dans un bout de code à cause d'un autre bout de code foireux..

          peut etre avec uml..

          valgrind linux --root=... ;o)

        • [^] # Re: sur PPC aussi...

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

          Ah oui, là, le doute n'est plus possible...

          Et en français, ça donne quoi ?

          • [^] # Re: sur PPC aussi...

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

            Sur le noyau 2.6, les erreurs de segmentation sont affichées avec une trace d'exécution inversée dans le tampon de messages du noyau.

            Tu trouves ça plus clair?
            Sérieusement, lordcow demande si on peut débugger des modules noyau avec valgrind. J'en déduis qu'il connaît le domaine du développement noyau donc je lui ai répondu avec le vocabulaire adapté au domaine, sans réfléchir que ce n'était pas forcément clair. Demander des explications sans ironie, c'est possible aussi.

  • # Valgrind libre

    Posté par  . Évalué à 4.

    IBM a acheter Rational qui possédait des brevets utilisés par Valgrind. Or il y a quelques semaines IBM a annoncé autoriser l'utilisation de ses brevets par le LL.

    Donc Valgrind est maintenant un "vrai" logiciel libre.

    • [^] # Re: Valgrind libre

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

      Et il y avait eu des menaces du cote de valgrind ? Comme il s'appuie sur pas mal de trucs publies, il se peut que les brevets ne valent pas un clou.

      • [^] # Re: Valgrind libre

        Posté par  . Évalué à 5.

        > il se peut que les brevets ne valent pas un clou.

        Si, ils sont tout à fait valables.
        Valables selon Red Hat et c'est pour celà que Valgrind n'était pas diffusé par Red Hat/Fedora.
        Ben Valgrind a fait son apparation il y a quelques semaines dans Fedora Core.

        Ce problème était dans bugzilla de Red Hat :
        https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78403(...)

        Le bug est maintenant fermé.

        > Et il y avait eu des menaces du cote de valgrind ?

        Mauvais cette façon d'aborder les brevets/copyright/etc.

        SCO n'est pas prévenu avant de faire chier. Heureusement pour nous, ça ne marche pas.

      • [^] # Re: Valgrind libre

        Posté par  . Évalué à 2.

        Pour info, Rational a développé Purify (bien avant Valgrind).

        • [^] # Re: Valgrind libre

          Posté par  . Évalué à 5.

          Je vais peut-être dire un bétise mais purify et valgrind ne fonctionne pas du tout de la même façon:

          - valgrind "émule" un processeur et intercepte les accès mémoire.
          Valgrind s'utilise à l'exécution d'un programme.

          - purify "instrumente" un exécutable pour inserer du code avant chaque accès mémoire pour valider si celui-ci est correct. Purify s'utilise à l'édition des liens d'un exécutable.


          Cette différence architecture permet à valgrind d'être utilisable sur la plupart des codes (exécutable, bibliothèque dynamique, ...) là où le concurent de Rational n'est capable que de gérer des exécutables (ciao jni!)

          Cependant, cette architecture semble avoir un prix: il parait délicat de faire un portage de valgrind sur d'autre type de plate-forme (sun/solaris, mips/SGI, ...).


          J'ai du mal à voir ce que Rational a pu breveté d'autre que "on vérifie que l'accès mémoire est correct". On serait bien loin de la technique.... Et cette idée me parait presque aussi vielle que les OS mutli-taches.

          • [^] # Re: Valgrind libre

            Posté par  . Évalué à 0.

            > J'ai du mal à voir ce que Rational a pu breveté

            Quand je dit que les brevets Rational (maintenant IBM) sont valables, je dis valable pour une agence de brevet, la justice.
            Pour moi un brevet n'est pas valable.

      • [^] # Re: Valgrind libre

        Posté par  . Évalué à 5.

        > Comme il s'appuie sur pas mal de trucs publies

        Par définition un brevet est publié.

        PS : les accents et les claviers azerty ne sont pas brevetés.

        • [^] # Re: Valgrind libre

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

          Je parlais de documents publies avant l'existence du brevet. Evidemment que le brevet est publie, c'est une des contreparties essentielles de son existence.

          • [^] # Re: Valgrind libre

            Posté par  . Évalué à 1.

            Ça impose de passer devant les tribunaux.
            En attendant, le brevet est valide.
            Que le brevet soit intelligent ou non, qu'il soit une copie de ce qui existait déjà depuis 200 ans, etc ne change rien à ça (malheureusement).

    • [^] # Re: Valgrind libre

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

      il y a quelques semaines IBM a annoncé autoriser l'utilisation de ses brevets par le LL.

      Donc Valgrind est maintenant un "vrai" logiciel libre.
      Et qu'est-ce qui empèche IBM de "changer d'avis" (même si ça semble peu probable) ? Il y a moyen de renoncer définitivement à un brevet ? Mettre un brevet dans le domaine public c'est possible ? (oui je sais copyright != brevet)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Valgrind libre

        Posté par  . Évalué à 1.

        > Et qu'est-ce qui empèche IBM de "changer d'avis"

        Excellente question !
        Ben Red Hat fait la même chose :-)
        Red Hat le fait dans une moins mesure et à ma connaissance Red Hat à moins de 10 brevets. C'est purement pour des raison défensive.
        Donc Red Hat reconnait la façon d'appliquer les brevets d'IBM et vice versa.

        De plus, IBM reconnait la GPL !
        Si IBM (RH fait de même) n'attaque pas un programme GPL qui utilise un de leur brevet, alors implicitement IBM reconnait que son brevet est "libre" pour le LL.

        > Il y a moyen de renoncer définitivement à un brevet ?

        IBM ne renonce pas à ses brevets. IBM n'applique pas de restriction pour l'utilisation de ses brevets dans les LL.

        • [^] # Re: Valgrind libre

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

          >> Il y a moyen de renoncer définitivement à un brevet ?
          >
          > IBM ne renonce pas à ses brevets. IBM n'applique pas de restriction pour
          > l'utilisation de ses brevets dans les LL.

          Oui mais ma question c'est "est-ce que légalement il est possible de renoncer définitvement à un brevet de manière à ne pas pouvoir revenir sur sa décision (un peu comme quand on met un truc dans le domaine public) ?"

          Je savais pas que RH détenait des brevets logiciel.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Valgrind libre

            Posté par  . Évalué à 1.

            > Oui mais ma question c'est "est-ce que ...

            Je ne sais pas.

            > Je savais pas que RH détenait des brevets logiciel.

            C'est sur toutes les pages de leur site web :-)
            Recherche "patent" sur une page et tu tombes sur :
            http://www.redhat.com/legal/patent_policy.html(...)

            Ça explique la position de Red Hat et son engagement envers le LL.

          • [^] # Re: Valgrind libre

            Posté par  . Évalué à 1.

            Pour RedHat la situation est un peu differente par rapport a IBM: ils distribuent du logiciel GPL donc ils autorisent tout le monde a utiliser/redistribuer leur code meme s'ils ont des patentes, enfin je crois que la GPL dit ,ca.

            Par contre IBM pour autant que je sache distribue peu de software sous GPL, donc a priori je ne vois pas ce qui les empecherait de changer d'avis..

  • # Moi,je ...

    Posté par  . Évalué à 4.

    Juste pour info , moi , j'utilise dmalloc , ca marche sur plein de machines mais pas d'interface graphique.
    Il simule les malloc par des malloc à lui juste en utilisant sa librairie à la place de la lib standard.

    lien : http://dmalloc.com/(...) (project sourceforge)
    Comme ca, si le probléme est sur une autre machine, c'est plus facile à debugger.

    par contre, je n'ai jamais utilisé valgrind, il faudrait que le le teste sur un de mes prog. pour voir ce que ca donne.

    • [^] # Re: Moi,je ...

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

      Comme alternative il y a aussi electric fence: http://perens.com/FreeSoftware/(...)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Moi,je ...

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

      dmalloc est bien pour les malloc... mais Valgrind en fait beaucoup plus en terme de verifications memoire. beucoup, beaucoup plus.

      Tu ne devrais pas etre decu, si ton appli est un peu consequente.
      (valgrind est a la ligne de commande, il n'y a pas interfaces graph)


      Pour cause de C++ et STL, j'utilise plutot le code de Paul Nettle
      http://www.fluidstudios.com/(...)

      Il est vraiment tres bien, en plus de logguer tous les leaks dans un fichier en donnant le numero de ligne et le fichier de l'allocation, il leve des exceptions en cas de probleme (mauvaise correspondance new/delete[] par exmple.)

      Mais pour etre sur, il faut Valgrinder de temps a autre.

      • [^] # Re: Moi,je ...

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

        >Pour cause de C++ et STL, j'utilise plutot le code de Paul Nettle
        hmm, ambigue...

        Je precise, le plutot c'est par rapport a dmalloc et electric fence, pas pour valgrind.

        Valgrind supporte tres bien le C++ et STL

        (lors des premieres version de valgrind, les devs Kde a trouve un paquet impressionnant de bugs dans leur code...)

  • # Pas mal mais peut faire mieux

    Posté par  . Évalué à 2.

    Bon je viens de tester la dernière version de valgrind et cela ne me satisfait toujours pas pour un problème assez ennuyeux.

    En gros les problèmes les plus fréquents que j'ai en C sont :
    1) débordement de tableaux alloués statiquement
    2) débordement de tableaux alloués dynamiquement
    3) problème de libération mémoire et/ou de fermeture de fichiers
    4) variables non initialisées et utilisées

    J'utilise en ce moment Purify qui détecte très bien les 2-3-4) et pas très bien le 1) et je vais bientôt tester Insure++ qui devrait détecter les 1-2-3-4) (ces logiciels sont payants)

    Le plus embêtant reste le 1) et valgrind ne le détecte pas très bien (créer un tableau de 3 éléments et aller taper sur le 4e, il ne bronchera pas).

    Je n'ai trouvé qu'un seul 'truc' gratuit qui détecte bien le 1) et c'est l'option (ou patch ?) bounds-checking de gcc. C'est vraiment pas mal du tout et ça gagnerait à être plus connu...

    Pour info, Purify intervient au niveau de l'édition de lien (breveté !) et Insure++ au moment de la compilation (breveté !).
    Valgrind c'est encore une autre histoire (émulation d'un proc) et bounds-checking je ne sais pas du tout...

Suivre le flux des commentaires

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