C++, string et valgrind

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:

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:

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

voilà le retour:

Citation:

==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":

Citation:

==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]

RE: C++, string et valgrind

le question est si bête que cela ?

Re: RE: C++, string et valgrind

Citation:

Envoyé par Alcée

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).

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

merci pour les réponses
@+