Discussion :

[Alc�e]

Bonjour,
En jouant un peu avec valgrind, j'ai trouv� quelque chose de bizarre. J'aurais voulu savoir si c'�tait reproductible chez quelqu'un d'autre. Et si oui si quelqu'un avait un explication/r�solution (solution : mauvais codeur je suis )
Valgrind m'indique que j'ai du code "still reachable". Cela le fait avec un code complexe mais aussi avec quelque chose d'aussi "simple" que cela du moment qu'il y a des string de la STL :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
#include <string>
int main () {
        std::string test = "bonjour";
        return 0;
}

Peut pas faire plus simple. on compile avec g++-3.3.
Et avec cette ligne, on lance valgrind:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

valgrind --leak-check=yes  --show-reachable=yes --num-callers=20  ./a.out

voil� le retour:

==29797== Memcheck, a memory error detector for x86-linux.
==29797== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==29797== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==29797== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==29797== For more details, rerun with: -v
==29797==
==29797==
==29797== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==29797== malloc/free: in use at exit: 960 bytes in 1 blocks.
==29797== malloc/free: 1 allocs, 0 frees, 960 bytes allocated.
==29797== For counts of detected errors, rerun with: -v
==29797== searching for pointers to 1 not-freed blocks.
==29797== checked 2388556 bytes.
==29797==
==29797== 960 bytes in 1 blocks are still reachable in loss record 1 of 1
==29797== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==29797== by 0x1B9A0A5A: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x1B9A096C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x1B9A0667: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x1B9A5FF7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x1B9A6D4F: (within /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x1B9A34A8: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7)
==29797== by 0x80485A9: main (in /tmp/a.out)
==29797==
==29797== LEAK SUMMARY:
==29797== definitely lost: 0 bytes in 0 blocks.
==29797== possibly lost: 0 bytes in 0 blocks.
==29797== still reachable: 960 bytes in 1 blocks.
==29797== suppressed: 0 bytes in 0 blocks.

Et plus votre code utilise d'objet de la STL et plus la quantit� de m�moire augmente.
Suis-je compl�tement � la masse, fais-je quelque chose de mal ?
please help !!!!

Avec g++3.4 le retour est encore "pire":

==29816== Memcheck, a memory error detector for x86-linux.
==29816== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==29816== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==29816== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==29816== For more details, rerun with: -v
==29816==
==29816==
==29816== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==29816== malloc/free: in use at exit: 4438 bytes in 8 blocks.
==29816== malloc/free: 8 allocs, 0 frees, 4438 bytes allocated.
==29816== For counts of detected errors, rerun with: -v
==29816== searching for pointers to 8 not-freed blocks.
==29816== checked 2473300 bytes.
==29816==
==29816== 20 bytes in 5 blocks are still reachable in loss record 1 of 4
==29816== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==29816== by 0x1B96E5EE: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B96E845: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A2D29: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A5476: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A559B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x80485B4: main (in /tmp/a.out)
==29816==
==29816==
==29816== 80 bytes in 1 blocks are still reachable in loss record 2 of 4
==29816== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==29816== by 0x1B96E5AE: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B96E845: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A2D29: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A5476: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A559B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x80485B4: main (in /tmp/a.out)
==29816==
==29816==
==29816== 258 bytes in 1 blocks are still reachable in loss record 3 of 4
==29816== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==29816== by 0x1B96E55B: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B96E845: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A2D29: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A5476: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A559B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x80485B4: main (in /tmp/a.out)
==29816==
==29816==
==29816== 4080 bytes in 1 blocks are still reachable in loss record 4 of 4
==29816== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==29816== by 0x1B96E9DD: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A2D29: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A5476: (within /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x1B9A559B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3)
==29816== by 0x80485B4: main (in /tmp/a.out)
==29816==
==29816== LEAK SUMMARY:
==29816== definitely lost: 0 bytes in 0 blocks.
==29816== possibly lost: 0 bytes in 0 blocks.
==29816== still reachable: 4438 bytes in 8 blocks.
==29816== suppressed: 0 bytes in 0 blocks.

Alc�e

[Balises [code] et [quote] ajout�es par Aur�lien]

[Alc�e]

le question est si b�te que cela ?

[Grulim]

le question est si b�te que cela ?

il est clair que le code d'exemple que tu fournis n'est pas bogu� (ou alors moi aussi je suis � la masse) et ne contient pas de fuite de m�moire, �a me conduit � penser que valgrind a un pb avec la STL (du moins ta version).

[JolyLoic]

Question pos�e il y a peu sur fr.comp.lang.c++.

Voici quelques liens dessus :
http://www.google.fr/groups?selm=41c97102%240%2430789%248fcfb975%40news.wanadoo.fr
http://www.google.fr/groups?threadm=41c97102%240%2430789%248fcfb975%40news.wanadoo.fr

[Alc�e]

merci pour les r�ponses
@+