Valgrind 1.9.5

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
8
avr.
2003
Technologie
Valgrind est un outil de vérification de code à l'execution. Le code est exécuté dans une machine virtuelle qui vérifie les appels, adresses memoires, etc.

Cette nouvelle version (stable) apporte les « skins », qui permettent de sélectionner ce que l'on veut tester dans la machine virtuelle (ex : -skin=memcheck). Ainsi l'exécution est plus rapide, parce que moins coûteuse en vérification. De plus, l'ajout de plugins sous forme de "skins" pour valgrind est plus simple.

Cela permet de trouver des bugs dans vos programmes sans avoir à recompiler !

À noter : ne marche pas sur Redhat 9 à cause de la nouvelle bibliothèque NPTL.

Autre nouveauté, des projets d'interface graphique pour Valgrind sont en cours.

Aller plus loin

  • # Re: Valgrind 1.9.5

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

    valgrind c'est du bonheur à tartiner

    • [^] # Re: Valgrind 1.9.5

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

      On ne demande qu'à le croire.
      Mais, est-ce qu'il a une barre de progression dans le splashscreen ?

    • [^] # Re: Valgrind 1.9.5

      Posté par  . Évalué à 5.

      Oui je le découvre avec cette nouvelle et je dois dire que c'est vraiment excellent ! En quelques minutes et à peu de frais j'ai trouvé 3 bugs dans l'interpréteur du GOTO++. Vive Valgrind !

      • [^] # Re: Valgrind 1.9.5

        Posté par  . Évalué à 3.

        Donc t'en as plus que pour... 6 à 8 mois pour que ça devienne à peu près correct ;o)

      • [^] # Re: Valgrind 1.9.5

        Posté par  . Évalué à 2.

        Ouaip valgrind power !

        De plus, avec les versions 1.9.x, fini aussi les fausses alertes dues à des optimisations du compilateur. Par contre dans les versions instables ca avait tendance a marcher nickel... jusqu'au moment ou ca se gelait sans plus rien faire du tout :-( espérons que ca soit corrigé.

  • # Re: Valgrind 1.9.5

    Posté par  . Évalué à 9.

    Ajout:
    il y a aussi un tres bon plugin d'integration de valgrind dans la version cvs de kdevelop (gideon):
    http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdevelop/parts/valgrind/(...)

    a mon avis il ne gere par la branche 1.9.x de valgrind mais ca ne saurait tarder.

  • # Re: Valgrind 1.9.5

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

    > ne marche pas sur Redhat 9 à cause de la nouvelle bibliothèque NPTL.

    si je voulait lancer un troll, je dirais que c'est trés "propriétaire" comme méthode ...

    Aller, soyons fou, lançons le troll.
    À quoi ça sert d'avoir des Xps si c'est pas pour les cramer :-)

    Donc, je trouve que RedHat profite de sa position de leader pour imposer des changements.
    Bientot, les gens vont être obligés de les suivre, car le programme ne sera certifiés que pour tourner sur la version avec NPTL, et une fois de plus, on va assister a un exemple d'obsolesense programmée.

    Heuresement, on peut recompiler les sources. Mais, je ne pense pas qu'un tel mouvement soit bon pour le developement d'applis commerciales.

    • [^] # Re: Valgrind 1.9.5

      Posté par  . Évalué à 10.

      Petite precisions:

      En fait la NPTL est compatible de facon binaire et source avec les anciennes threads (les LinuxThreads) c'est juste la methode de fonctionnement interne (des threads kernel au lieu de threads users pour l'ancienne) qui differe.
      Le probleme vient que certaines applis faisant du tres bas niveau avec les threads (wine, valgrind, ...) ne fonctionnent plus tres bien car se basaient sur l'ancien comportement (et surtout le fait que les threads etaient gerees en user mode).

      Moi je suis tout a fait d'accord que la lib NPTL est la voie a suivre (surtout que les LinuxThreads c'etait plus un vieux hack qu'autre chose) maintenant, le fait de l'imposer comme ca dans une distrib grand publique alors que des logiciels importants impactes ne savaient toujours pas comment s'integrer, je pense que ca n'est vraiment pas une terrible idee.

      D'ailleurs au niveau de wine, malgre le fait qu'ils ont bien bosse dessus il y a encore de nombreux problemes.

      • [^] # Re: Valgrind 1.9.5

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

        les pthread en user mode ... ah non pas d'accord du tout
        d'ailleurs c simple tu lance un prog multi-thread sous linux et tu fait un top
        ils ne sont pas en user mode et tu le vera.
        par contre la Gnu Posix Thread Librarie (Gnu Pth) elle fait effectivement des thread usermode mais elle n'est pas utilise par defaut

        • [^] # Re: Valgrind 1.9.5

          Posté par  . Évalué à 3.

          C'etait un abus de langage en fait
          les LinuxThreads n'ont pas un mapping 1:1 par rapport aux threads kernel mais plutot n:p. C'est donc a la charge d'un ordenanceur en user mode (afin de decider qu'elle threads "posix" vont sur quel pool gere par une thread kernel) que ce gere les linuxthreads.
          En jouant avec les options tu peut simuler une comportement 1:1, mais sachant que le kernel n'a pas trop notion de ce que tu trafique (sinon que tu a utilise clone comme un warrior) il gere ca comme une mer...

          • [^] # Re: Valgrind 1.9.5

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

            les LinuxThreads n'ont pas un mapping 1:1 par rapport aux threads kernel mais plutot n:p

            hum, non, les LinuxThreads ainsi que la NTPL sont 1-on-1. http://people.redhat.com/drepper/nptl-design.pdf(...)

            Tu confonds peut-être avec NGPT http://www-124.ibm.com/developerworks/oss/pthreads/(...) une implémentation faite par IBM, dérivée de GNU Pth est qui elle est M-on-N.

            • [^] # Re: Valgrind 1.9.5

              Posté par  . Évalué à 1.

              Autant pour moi, tu as raison

              J'ai du faire trop de threading sur SUN dernierement au point de me melanger un peu les pinceaux.
              Enfin au final, ca change pas que les LinuxThreads c de la m... et dire que j'en ai passer des journees a me battre avec pour avoir des applis qui deadlock pas, sniff ca va me faire un choc de plus galerer comme ca.

              • [^] # Re: Valgrind 1.9.5

                Posté par  . Évalué à 1.

                heuuu pour moi, les deadlock c un probleme de conception de l'appli, pas du systeme de thread. Enfin, c'est ce qu'on m'a appris :)

                • [^] # Re: Valgrind 1.9.5

                  Posté par  . Évalué à 1.

                  ben essaye de jouer avec les threads sous linux tu va voir que c tres facile alors d'eavori une appli "mal concue" :p

  • # Re: Valgrind 1.9.5

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

    Ne pas l'utiliser serait presque un crime, de nos jours!

  • # Re: Valgrind 1.9.5

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

    Question d'un ignorant qui n'a jamais utilisé Valgrind :

    Est-ce que ça apporte quelque chose ou au contraire est-ce qu'il manque encore des choses par rapport à des languages comme Ada ou Java, ou les erreurs d'accès mémoire lèvent une exception à l'execution ?

    En fait, j'aurais prèsque l'impression que ce genre d'outil existe surtout pour palier à la faiblesse d'un langage comme le C pour ce qui est des vérifications à l'execution.

    (Oui, les vérifications à l'execution ralentissent l'execution du programme, mais oui, en Ada au moins, on peut les désactiver avec un flag de compil')

    • [^] # Re: Valgrind 1.9.5

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

      Valgrind ne détecte pas tout (tu peux écraser les variables de la pile comme bon te semble) mais il détecte beaucoup. Et en particulier l'usage de valeurs non initialisées, avec une précision au bit près: là dessus un compilo ne peut rien faire, sinon initialiser toutes les variables a leur déclaration (l'ada fait ça ?), et ça aussi ça coûte.

      • [^] # Re: Valgrind 1.9.5

        Posté par  . Évalué à 3.

        Valgrind ne détecte pas tout (tu peux écraser les variables de la pile comme bon te semble) mais il détecte beaucoup.

        En fait pour les variable que tu compte surveiller "sur la pile" valgrind exporte des nombreuses et jolies macros pour ca (et bien d'autres choses cf <valgrind/memcheck.h>).

        • [^] # Re: Valgrind 1.9.5

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

          c'est vrai que j'ai jamais essayé de me servir des macros de valgrind.. ça change un peu l'approche (devoir modifier le code) mais c'est ptet pas mal.
          Comment tu l'utilises, tu truffes ton code de VALGRIND_CHECK_READABLE et consorts ou bien tu l'ajoute temporairement dans le source en cas de chasse au bug ?

          • [^] # Re: Valgrind 1.9.5

            Posté par  . Évalué à 5.

            un truc comme ca, ca devrait aller :)

            #if defined(DEBUG) && defined(HAVE_VALGRIND_MEMCHECK_H)
            # include <valgrind/memcheck.h>
            # define VG_MARK_INACCESSIBLE(p,l) VALGRIND_DISCARD( VALGRIND_MAKE_NOACCESS( (p), (l) ) )
            # define VG_MARK_UNINITIALIZED(p,l) VALGRIND_DISCARD( VALGRIND_MAKE_WRITABLE( (p), (l) ) )
            #else /* VALGRIND */
            # define VG_ MARK_INACCESSIBLE(p,l)
            # define VG_MARK_UNINITIALIZED(p,l)
            #endif /* VALGRIND */

      • [^] # Re: Valgrind 1.9.5

        Posté par  . Évalué à 5.

        Oui, Ada permet une telle vérification, cf le pragma Normalize_Scalars qui fait partie des pragma spécifiques d'une implémentation. GNAT, le front-end Ada présent dans GCC, le supporte,

        Ce pragma permet de vérifier que les variables sont bien initialisées, mais seulement celles de type scalaire. L'idée semble-t-il est d'initialiser par défaut avec une valeur telle qu'une exception est levée lorsque l'on accède à une valeur non initialisée.

        De plus, par défaut les types accès (en gros les pointeurs de Ada) sont initialisés à une valeur nulle, cela évite de pointer sur n'importe quoi ..

        A noter par ailleurs que les mécanismes de protection de Ada font qu'une bonne partie des bugs que Valgrind permet de détecter peuvent l'être directement lors de l'exécution d'un programme Ada en se basant sur les exceptions levées par la runtime.

        Si cela ne suffit pas, certains packages permettent la redéfinition de l'allocation et désallocation de la mémoire et ainsi de tracer ce qui se passe. Ainsi GNAT.Debug_Pools ajoute un certain nombre de vérifications lors d'accès mémoire et permet de vérifier les accès mémoires au prix (il est vrai) d'une recompilation.

  • # Re: Valgrind 1.9.5

    Posté par  . Évalué à 5.

    Et pour tous les utilisateurs des drivers NVidia : oui, ce Valgrind là, contrairement à la série 1.0.x , tolère sans problème les applis liées aux biblios OpenGL...

Suivre le flux des commentaires

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