Valgrind 1.0.0

Posté par  (site web personnel) . Modéré par Brice Favre.
Étiquettes :
0
29
juil.
2002
Linux
Valgrind (NdM : GPL) permet d'evaluer, a posteriori, la gestion de la memoire dans un programme, du même type que mpatrol (NdM : LGPL) ou dmalloc (NdM : libre) ou purify (NdM : propriétaire) sans recompilation du code. Il permet de détecter les problèmes suivants :
* Utilisation de memoire non initialisée
* Lecture/écriture de blocs liberés
* Lecture/écriture au delà d'un bloc alloué
* Lecture/ecriture de zones non autorisées de la pile
* Fuites de mémoire
* Passage de bloc non initialisés ou inaccessibles à des appels système
* Mauvaise utilisation des fonctions et opérateurs malloc/new/new [] par rapport à free/delete/delete []

Javais testé certaines versions précédentes et c'était impressionnant (un chouya mieux que mpatrol que je connais bien) !

Note du modérateur : il ne fonctionne que sur Linux x86, mais il est effectivement assez impressionnant.

Aller plus loin

  • # cool

    Posté par  . Évalué à 10.

    qui se devoue pour poster l'url au developpeurs des chez nvidia ? :)

    allez hop -1

    • [^] # Re: cool

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

      « NVidia's OpenGL drivers (libGL.so) use segment override instructions, which Valgrind doesn't support (yet). You can workaround this by using the Mesa OpenGL drivers instread, or rebuilding your system (Qt, for example), without GL support. »

      C'est sûr, ça va leur plaire cette page.

      • [^] # Re: cool

        Posté par  . Évalué à -5.

        segment override instructions: ben voila on chechait d'ou venaient les problemes de memoire des drivers nvidia :)
        bon -1 pour mechanceté gratuite...

      • [^] # Re: cool

        Posté par  . Évalué à -2.

        Bah voilà...
        Deux heures que j'essayais de poster cet extrait.
        Pas moyen. Dix lignes pour un commentaire ça parait insurmontable aux serveurs ?

        -1 parce que se défoule parce que énervé.
        Et vivement le ouikènd.

      • [^] # Re: cool

        Posté par  . Évalué à 6.

        NVidia's OpenGL drivers (libGL.so) use segment override instructions

        Ah la beauté du x86... Je me souviens des %fs et %gs qui se baladaient dans mon code quand j'accédais au framebuffer sous Ms-Dos ;)

        • [^] # Bug Valgrind

          Posté par  . Évalué à 3.

          Pour ceux qui ne connaitrait pas l'assembleur, ici c'est Valgrind qui est "buggé" (incomplet), pas Nvidia.

          Valgrind est en effet une sorte d'émulateur x86, dont l'auteur implémente les instructions à la demande (c'est à dire qu'il attends que les gens se plaignent pour le faire).

          Ici, l'émulateur dit qu'il ne n'est pas capable d'interpréter les instructions avec un préfixe de segment genre "es:" (si le segment par défaut est "ds").

          • [^] # Re: Support Valgrind incomplet

            Posté par  . Évalué à 2.

            Il faut rappeler aussi que ces prefixes de segment sont un peu un des archaismes de l'architecture x86. Ils permettaient a l'epoque du 8086/80286 d'acceder "facilement" a plus de 64ko en changeant le prefixe par defaut. (Les 64ko c'est les 16 bits des registres, et l'addressage memoire segmenté permettait d'aller au dela).

            Depuis l'apparition du 386, c'est beaucoup moins utile puisque l'on peut adresser a plat 4go (32 bits des registres, et le segment de donne par defaut (ds pour data segment est utilise). Bref les compilos ne generent plus souvent des instructions avec des prefixes (qui sont devenu couteux en temps d'execution). Pourquoi Nvidia utilise encore ce truc la, je ne sais pas...

  • # Pour info

    Posté par  . Évalué à 10.

    Les développeurs de KDE (pas de troll) l'utilisent. C'est même en lisant un article (argh plus l'URL) où ils expliquent les outils utilisés que j'ai découvert valgrind.

    Je vais essayer la dernière version ...

    • [^] # Re: Pour info

      Posté par  . Évalué à 8.

      L'adresse de download est d'ailleurs chez developer.kde.org
      C'est un sujet sensible chez kde, les prcohaines glibc et gcc permettront d'améliorer tout ça.
      Zut, un myth de moins pour kde.

  • # atomique

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

    C'est vraiment de la balle atomique, et tout bon programme devrait pouvoir passer à travers. En plus ca s'utilise finger in ze noze, pas besoin de recompiler l'appli :)
    ca permet meme de savoir exactement où on pert des blocs mémoires. Le meilleurs de ceux que j'ai utilisé.
    reste a corriger les false positives et voila!

    • [^] # Re: atomique

      Posté par  . Évalué à 6.

      En plus ca s'utilise finger in ze noze, pas besoin de recompiler l'appli :)
      Oui, mais si j'ai bien compris, ça marche pas top top avec les instructions supplémentaires mmx et autres.

  • # valgrind c Bien

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

    valgrind roxor, il est vraiment une tête au-dessus des mallocs-debuggers "classiques". Ses seuls inconvenients sont:
    - des "faux"-warnings parfois un peu gênants dans les lib externes (libc, libX11..). Il possède une liste prédéfinie pour les éliminer, mais je suppose que celle-ci ne s'adapte parfaitement qu'à la redhat de l'auteur de valgrind.
    - l'execution du code sous valgrind est très sensiblement ralentie (à l'oeil je dirais entre 20 et 50 fois), du coup on ne peut pas envisager de lancer systématiquement le code sous valgrind pour ramasser les bugs qui passent.

    Ça ne l'empêche pas de roxer.

    • [^] # Re: valgrind c Bien

      Posté par  . Évalué à 9.

      Il possède une liste prédéfinie pour les éliminer, mais je suppose que celle-ci ne s'adapte parfaitement qu'à la redhat de l'auteur de valgrind.
      Il est possible d'y définir ses propres lib. Mais je dois avouer ne pas avoir encore essayer.

    • [^] # Re: valgrind c Bien

      Posté par  . Évalué à 10.

      Effectivement, la doc de valgrind annonce un ralentissement de 25 à 50 fois de l'application. Mais bon, étant donné tout ce que valgrind fait "par derrière" l'application, c'est un peu normal.

      Quant à la liste des exclusions pour les librairies externes (lic, libX11, ...), elle est générée par le script configure. Donc, si ce script est bien fait, la liste s'adaptera automatiquement au système de l'utilisateur (puisque configure peut connaître assez précisément les libs de la machine).

      Note : tout cela est tiré de la doc, je n'ai pas encore testé.

      Zeiram

    • [^] # Re: valgrind c Bien

      Posté par  . Évalué à -2.

      du coup on ne peut pas envisager de lancer systématiquement le code sous valgrind pour ramasser les bugs qui passent

      change de langage

  • # Licence et portabilite

    Posté par  . Évalué à 10.

    Comme j'ai mal lu la news, j'ai cru comprendre que dmalloc ET mpatrol ET purify etaient proprietaires. Verification faite, voici les precisions. N'oublions pas non plus electricfence dont le role n'est pas tout a fait le meme mais qui rend aussi quelques services

    dmalloc: licence de logiciel libre
    Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of Gray Watson not be used in advertising or publicity pertaining to distribution of the document or software without specific, written prior permission.

    Ajoutons que l'auteur aimerait qu'on lui fasse un don si son logiciel a aide a faire gagner du temps ou de l'argent.

    mpatrol: licence GPL

    valgrind: licence GPL
    Licence GPL malgre un titre sur la page principale comme quoi il n'est qu'open source.

    purify: proprietaire
    http://www.rational.com/products/purify_unix/(...)
    No comment.

    electricfence: licence GPL
    http://perens.com/FreeSoftware/(...)


    portabilite
    valgrind: ix86 seulement

    dmalloc: AIX, BSD/OS, DG/UX, Free/Net/OpenBSD, GNU/Hurd, HPUX, Irix, Linux, MS-DOG, NeXT, OSF, SCO, Solaris, SunOS, Ultrix, Unixware, Windoze, and even Unicos on a Cray T3E.

    mpatrol: AIX 4.1 DG/UX 4.11, 4.20 DRS/NX 6.2 DYNIX/ptx 4.5 FreeBSD 4.2 HP/UX 10.20 IRIX 5.3 Red Hat Linux 5.1, 6.0, 6.1, 6.2, 7.0, 7.1 SuSE Linux 7.1 LynxOS 3.0.0 SINIX 5.43 Solaris 2.5, 2.6, 7, 8 Tru64 5.0 UnixWare 7.1.1 AmigaOS 3.1 Windows NT 4.0 (et surement d'autres versions de tous ces OS!)

    purify: No comment: c'est proprietaire

    electricfence: y'a pas grand chose d'ecrit, mais je l'ai deja teste avec succes sur ix86 et sur solaris (sparc) 2.6


    Le bonjour chez vous,
    Yves

    • [^] # Re: Licence et portabilite

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

      Juste un petit "comment" sur purify : il n'est pas disponible sous Linux.

      • [^] # Purify

        Posté par  . Évalué à 4.

        Et pourtant il tourne sous Solaris.

        Comme quoi il doit y avoir beaucoup moins de leurs clients qui développent sous Linux que sous Solaris (sinon ils auraient fait le portage pour gagner plus de sous).

    • [^] # Re: Licence et portabilite

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

      Dans la liste il manque aussi Insure++ de parasoft (propio) mais mes tests n'ont pas ete tres concluant pour le C++.

    • [^] # Re: Licence et portabilite

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

      Un commentaire que j'avais déjà fait, un peu mis à jour :

      dmalloc
      http://dmalloc.com/(...)
      libre
      Multi-plateforme
      C/C++
      Nécessite une recompilation
      Supporte le multi-thread
      Version 4.8.2

      ccmalloc
      http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/(...)
      Fuites de mémoire et problèmes de mémoire
      GPL
      Linux et Solaris
      Nécessite une recompilation
      Version 0.3.9

      Electric Fence (efence)
      http://perens.com/FreeSoftware/(...)
      GPL
      Détection des dépassements de limites
      C
      Version 2.2.2

      Valgrind
      http://developer.kde.org/~sewardj/(...)
      Problèmes de mémoire (dont fuites)
      Pour x86 linux.
      Sans recompilation
      C/C++
      J'aime beaucoup
      Version 1.0

      Boehm Collector
      http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)
      Garbage collector et détecteur de fuites
      Licence compatible Debian en tout cas
      Multi-plateforme
      C/C++

      Parallel Collector on Message Passing Environment
      http://www.yl.is.s.u-tokyo.ac.jp/gc/dgc/(...)
      Licence inconnue (pas de téléchargement)
      Adresse de téléchargement invalide

      LeakTracer
      http://www.andreasen.org/LeakTracer/(...)
      Fuites de mémoire
      Linux et d'autres Unix
      Domaine public
      Sans recompilation
      C++
      Version 2.2

      MemWatch
      http://www.linkdata.se/sourcecode.html(...)
      Fuites de mémoire
      Domaine public
      Nécessite une recompilation
      C
      Version 2.67

      Memprof
      http://people.redhat.com/otaylor/memprof/(...)
      Profil de la mémoire allouée et détection des fuites (avec GUI)
      GPL
      C. C++ ?
      Sans recompilation
      Version 0.4.1

      mpatrol
      http://www.cbmamiga.demon.co.uk/mpatrol/(...)
      GPL
      Peut s'utiliser avec ou sans recompilation,
      Possibilité d'utiliser l'option -fcheck-memory-usage de gcc
      Un joli manuel bien fait
      Multi-plateforme, C/C++

      • [^] # Re: Licence et portabilite (memprof n'est plus maintenu)

        Posté par  . Évalué à 8.

        Remarque concernant memprof: il se semble plus maintenu.

        - l'URL de telechargement chez gnome est invalide.
        - La derniere entree dans le ChangeLog date du 9 fevrier 2001.

        Donc memprof, soit quelqu'un s'y colle pour le maintenir, soit on oublie

        Le bonjour chez vous,
        Yves

      • [^] # Boehm Collector

        Posté par  . Évalué à -3.

        concernant Boehm Collector,
        Ne l'utilisez pas en GC, c'est un principe de GC trop primitif pour être efficace (conservatif).

        Il vaut mieux un vrais GC dans un vrai langage, qu'un truc haxorisé dans un langage douteux pas prévu pour.

        Ceci dit il devrait être mieux que celui de OpenCascade et ses potes qui utilisent des smartPointers (un accès à l'objet pour chaque duplication ou suppression de référence).

        J'ai qd même l'impression qu'il est à racines ambigües, d'où la conservativité. Mais comment fait-il avec ceux qui bougent leurs indices dans leurs buffers ? il fait 2 comparaisons ? mort de rire.

        -1 c'est pas le genre de discours bienvenu ici

      • [^] # Re: Licence et portabilite

        Posté par  . Évalué à 1.

        waaaaa...
        quand je vois tout ca, je me dis que les projets C que j'ai rendu devaient pas etre folichons.
        Comprendre : Vu les mallocs et les strcpy que je te collais a droite et a gauche, ya des profs qu'on du avoir peur :)

        • [^] # projet C d'école

          Posté par  . Évalué à 0.

          Si t'as besoin d'un tel outil pour un petit projet c'est que tu connais mal le C, à mon avis. C'est d'ailleurs normal, vu que tu débute.

          Ce genre d'outils, c'est fait pour les gens qui écrivent des gros programmes de plusieurs milliers (voir centaines de milliers) de lignes, et qui ne peuvent plus garder la trace de leurs allocations... pas pour le TP de 50 lignes que tu fait en première année.

          • [^] # Re: projet C d'école

            Posté par  . Évalué à 2.

            C gentil ca de me faire passer pour un codeur limite capable de faire son sapin en asterisques...
            Pitit rectification:
            Je ne suis pas developpeur de formation mais sur les 3 mois de C que je me suis tapé, j'ai eu droit aux trucs comme huffman, listes chainees simples et doubles, etc...
            D'ailleurs, essais "dc" sous linux, c exactement ce que j'ai du faire...
            une calculatrice RAPIDE en précision infinie avec gestion de pile.et je t'assure que ca ne fait pas 50 lignes.

            • [^] # Re: projet C d'école

              Posté par  . Évalué à 0.

              ok je me suis trompé, je pensais que tu étais encore au stade TP de 1ere année.

              T'as du faire pas mal d'arbre alors (Huffman c'est à base d'arbre et la décomposition des expressions matheuse aussi).

              Au fait qu'est ce que tu entends par "calculatrice rapide" ?
              Sur PC standard, même une calculatrice pas rapide doit mettre moins d'un millième de seconde par opération ?
              Tu faisait de l'embarqué ?

              • [^] # Re: projet C d'école

                Posté par  . Évalué à 1.

                bah utilise dc (qui est quand meme mieux programme que mon projet) et demande lui de te fournir avec 100 millions de chiffre apres la virgule, le resultat de 1/9998887776665554443332222221110001112223334.11123123
                comme c a base de pile, tu rentres :
                1 puis 999888.... puis / et t'attend :)
                Non, je t'assure que meme un PII400 te sors pas les 1 millions de chiffre en 1 seconde...
                Sachant que les types utilisé étaient des chaines. quand j'y repense, c'etait assez marrant

                • [^] # Re: projet C d'école

                  Posté par  . Évalué à 0.

                  ça me rappelle un TP de 1ere année ISMRA ça ! coincidence ?


                  PII400 te sors pas les 1 millions de chiffre en 1 seconde..
                  Il pourrait pourtant ! ça nous laisserait 400 cycles par chiffres.

Suivre le flux des commentaires

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