------- Comment #4 from sakovacs at freemail dot hu 2006-04-08 02:58 -------
sorry, please disregard my last post, submitted too early...
Thanks for the very fast reply. I agree, that such a leakage would be very
unlikely. It must be something else, but I don't understand what, I've modified
the code:
#include <string>
#include <vector>
int max = 5000000;
void bad() {
std::vector<std::string> v;
for (int x = 0; x < max; x++) v.push_back(std::string("test"));
}
int main(int argc, char *argv[]) {
bad();
usleep(20000 * 1000);
return 0;
}
I've already tested with valgrind, restested this ^ version too, just like you
pointed it out on the link, the result is:
valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high
--show-reachable=yes ./t
==8291== Memcheck, a memory error detector.
==8291== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==8291== Using LibVEX rev 1367, a library for dynamic binary translation.
==8291== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==8291== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==8291== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
--8291-- Valgrind library directory: /usr/lib64/valgrind
--8291-- Command line
--8291-- ./t
--8291-- Startup, with flags:
--8291-- -v
--8291-- --num-callers=20
--8291-- --leak-check=yes
--8291-- --leak-resolution=high
--8291-- --show-reachable=yes
--8291-- Contents of /proc/version:
--8291-- Linux version 2.6.14-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.4
(Gentoo
3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #2 Tue Feb 28 22:00:41 JST 2006
--8291-- Reading syms from /mnt/evyrl/evyrl/Projects/evyrl/src/main/t
(0x400000)
--8291-- Reading syms from /lib/ld-2.3.5.so (0x11900000)
--8291-- Reading syms from /usr/lib/valgrind/stage2 (0x70000000)
--8291-- object doesn't have a symbol table
--8291-- Reading suppressions file: /usr/lib64/valgrind/default.supp
==8291==
--8291-- Reading syms from /usr/lib/valgrind/vg_preload_core.so (0x11A17000)
--8291-- object doesn't have a symbol table
--8291-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x11B18000)
--8291-- object doesn't have a symbol table
--8291-- REDIR: 0x1190EFA0 (index) redirected to 0x11B1BDA0 (index)
--8291-- REDIR: 0x1190F150 (strcmp) redirected to 0x11B1C250 (strcmp)
--8291-- REDIR: 0x1190F180 (strlen) redirected to 0x11B1BFE0 (strlen)
--8291-- Reading syms from
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6.0.3 (0x11C46000)
--8291-- Reading syms from /lib/libm-2.3.5.so (0x11E36000)
--8291-- object doesn't have a symbol table
--8291-- Reading syms from
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.4.4/libgcc_s.so.1 (0x11FBC000)
--8291-- Reading syms from /lib/libc-2.3.5.so (0x120C8000)
--8291-- object doesn't have a symbol table
--8291-- Reading syms from /lib/libdl-2.3.5.so (0x122ED000)
--8291-- object doesn't have a symbol table
--8291-- REDIR: 0x12136640 (rindex) redirected to 0x11B1BCA0 (rindex)
--8291-- REDIR: 0x12136230 (strlen) redirected to 0x11B1BFA0 (strlen)
--8291-- REDIR: 0x121364A0 (strncmp) redirected to 0x11B1C1D0 (strncmp)
--8291-- REDIR: 0x11CF5140 (operator new(unsigned long)) redirected to
0x11B1A380 (operator new(unsigned long))
--8291-- REDIR: 0x12137B60 (memcpy) redirected to 0x11B1C2B0 (memcpy)
--8291-- REDIR: 0x11CF3F10 (operator delete(void*)) redirected to 0x11B1AF80
(operator delete(void*))
--8291-- REDIR: 0x12130630 (free) redirected to 0x11B1AC60 (free)
--8291-- REDIR: 0x12137460 (memset) redirected to 0x11B1C710 (memset)
==8291==
==8291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 4)
--8291--
--8291-- supp: 3 index-not-intercepted-early-enough-HACK-1
--8291-- supp: 1 strlen-not-intercepted-early-enough-HACK-4
--8291-- supp: 1 strlen-not-intercepted-early-enough-HACK-3
--8291-- supp: 4 dl_relocate_object
==8291== malloc/free: in use at exit: 0 bytes in 0 blocks.
==8291== malloc/free: 1000021 allocs, 1000021 frees, 45777208 bytes allocated.
==8291==
==8291== No malloc'd blocks -- no leaks are possible.
--8291-- memcheck: sanity checks: 2156 cheap, 87 expensive
--8291-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--8291-- memcheck: auxmaps: 0 searches, 0 comparisons
--8291-- memcheck: secondaries: 1360 issued (87040k, 85M)
--8291-- memcheck: secondaries: 161 accessible and distinguished (10304k, 10M)
--8291-- tt/tc: 3550 tt lookups requiring 3607 probes
--8291-- tt/tc: 3550 fast-cache updates, 5 flushes
--8291-- translate: new 1675 (36624 -> 748979; ratio 204:10) [0 scs]
--8291-- translate: dumped 0 (0 -> ??)
--8291-- translate: discarded 11 (212 -> ??)
--8291-- scheduler: 107846433 jumps (bb entries).
--8291-- scheduler: 2156/2004138 major/minor sched events.
--8291-- sanity: 2157 cheap, 87 expensive checks.
--8291-- exectx: 4999 lists, 14 contexts (avg 0 per list)
--8291-- exectx: 2000051 searches, 3000073 full compares (1499 per 1000)
--8291-- exectx: 0 cmp2, 36 cmp4, 0 cmpAll
So indeed, no memory leaks. But even with export GLIBCPP_FORCE_NEW=1 and
export GLIBCXX_FORCE_NEW=1 (found on the link, also see
http://www.lrde.epita.fr/~akim/compil/assignments.split/Valgrind.html) the rss
remains high after test() finishes. If that is the standard behaviour of the
allocators (pooling?) than maybe they pool a bit too agressive?...
Thanks you the help again,
Sandor
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27079
