Articles précédents : Logiciel
- [16] iXQ passe au GPL
- [46] nouvelle version de GNU Entreprise
- [9] OpenXP : du shareware au logiciel libre
- [25] Mplayer 0.90 est enfin dispo
- [44] Nouvelle version de OpenSSH
- [14] Freeduc-cd peaufinée
- [35] Knoppix 3.2 MiB « Privacy Edition »
- [130] Un grand pas pour l'interface de KDE ?
- [1] JAC version 0.9.4 est disponible
- [21] Premier progiciel Linux agréé SESAM-Vitale
Liens connexes
- Valgrind (1387 hits)
- Interface graphique gnogrind (1090 hits)
- Interface graphique alleyoop (téléchargement) (1741 hits)
- Interface graphique alleyoop (capture) (1491 hits)
- Interface graphique alleyoop (capture 2) (947 hits)
- Interface graphique Valgui (833 hits)
Dépêche modérée par
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.
![[en]](../../../images/en.png)
Valgrind (1387 hits)-
Interface graphique gnogrind (1090 hits)
![[fr]](../../../images/fr.png)
Interface graphique alleyoop (téléchargement) (1741 hits)-
Interface graphique alleyoop (capture) (1491 hits)
-
Interface graphique alleyoop (capture 2) (947 hits)
-
Interface graphique Valgui (833 hits)
> Lire les commentaires (23 commentaires, moyenne: 3,3).
[+] Re: Valgrind 1.9.5
valgrind c'est du bonheur à tartiner
-
[+] [^]Re: Valgrind 1.9.5
Posté par Pierre Tramo (page perso, ) le 08/04/2003 à 10:52. (lien). É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 Sidoine de Wispelaere (page perso, ) le 08/04/2003 à 11:40. (lien). É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 Alexandre Beraud () le 08/04/2003 à 11:59. (lien). É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 let antibarbie = xp <- xp - 1 (page perso, ) le 08/04/2003 à 13:53. (lien). É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
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 Raphael Junqueira (page perso, ) le 08/04/2003 à 10:14. (lien). Évalué à 2.tiens g d'ailleurs surtout oublie celui-la (g honte surtout que je l'utilise tous les jours):
http://kcachegrind.sourceforge.net/(...)
un des rares outils qui facilite le developement industriel sous unix.
Re: Valgrind 1.9.5
> 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 Raphael Junqueira (page perso, ) le 08/04/2003 à 10:28. (lien). É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 -=[ Benoit Plessis ]=- (page perso, ) le 08/04/2003 à 11:16. (lien). É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--
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)-
[^]Re: Valgrind 1.9.5
Posté par Raphael Junqueira (page perso, ) le 08/04/2003 à 13:33. (lien). É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 Vivi (page perso, ) le 08/04/2003 à 18:00. (lien). É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 Raphael Junqueira (page perso, ) le 08/04/2003 à 20:01. (lien). É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 LeMagicien Garcimore () le 09/04/2003 à 07:28. (lien). É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 Raphael Junqueira (page perso, ) le 09/04/2003 à 08:14. (lien). É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
Ne pas l'utiliser serait presque un crime, de nos jours!
Re: Valgrind 1.9.5
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 Troy McClure (page perso, ) le 08/04/2003 à 11:10. (lien). Évalué à 11.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 Raphael Junqueira (page perso, ) le 08/04/2003 à 14:39. (lien). É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 Troy McClure (page perso, ) le 08/04/2003 à 15:07. (lien). É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 Raphael Junqueira (page perso, ) le 08/04/2003 à 19:52. (lien). É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 yoogx () le 08/04/2003 à 17:32. (lien). É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
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...
Cette page a été générée par Templeet en 0.1416s (dont 0.0505 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.