This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/20062] hash_map leak memory


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]