This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/20062] hash_map leak memory
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Feb 2005 18:51:04 -0000
- Subject: [Bug libstdc++/20062] hash_map leak memory
- References: <20050218181050.20062.arturas@inf.unibz.it>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From pcarlini at suse dot de 2005-02-18 18:51 -------
With valgrind, I cannot reproduce the problem on 3.3.3:
==32676== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==32676== malloc/free: in use at exit: 296360 bytes in 56 blocks.
==32676== malloc/free: 35224 allocs, 35168 frees, 894872 bytes allocated.
==32676== For counts of detected errors, rerun with: -v
==32676== searching for pointers to 56 not-freed blocks.
==32676== checked 2563516 bytes.
==32676==
==32676== LEAK SUMMARY:
==32676== definitely lost: 0 bytes in 0 blocks.
==32676== possibly lost: 0 bytes in 0 blocks.
==32676== still reachable: 296360 bytes in 56 blocks.
==32676== suppressed: 0 bytes in 0 blocks.
==32676== Reachable blocks (those to which a pointer was found) are not shown.
(N.B: usual spurious reachable due to the pool allocator)
neither on 3.4.3:
==32669== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==32669== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32669== malloc/free: 52749 allocs, 52749 frees, 809664 bytes allocated.
==32669== For counts of detected errors, rerun with: -v
==32669== No malloc'd blocks -- no leaks are possible.
In any case, even if hash_map leaks (I don't think so)... see libstdc++/19554.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20062