|
From: Tom H. <to...@co...> - 2007-11-14 15:46:58
|
In message <473...@ak...>
William Schauweker <wsc...@ak...> wrote:
> The problem could be some kind of pilot error, so for now I'll simply
> describe what I'm trying to do, and how:
>
> o Linux environment.
> o Trying to track down something holding or losing memory in a server
> written in c++.
> o Program shows an enormous jump in memory use - both vss and rss - when
> "work in progress" hits 40K - 50K records. (Memory jumps 50 megs.)
> o When WIP has been processed, memory use never goes back down.
> o Dynamic memory use:
> - vanilla C++ - objects being new'd/deleted.
> - certain amount of malloc/free.
> - large user of standard library strings.
>
> o After WIP has been processed, if I feed another 40K - 50K input
> records, memory use does not jump again - making me doubt that this is
> in fact a leak.
>
> My suspicion is that it is the standard library allocator holding onto
> blocks of memory for reuse.
It could be the standard C++ library hanging on to it, but that
should show up in valgrind. More likely it is glibc hanging on to
it as malloc/free don't normally return freed memory to the system.
> But the valgrind summary - printed when the service exits - shows no
> memory use that comes close to explaining the high vss/rss size. The
> largest block of memory outstanding is due to "Deque". But that memory
> is 800KB, vs the 50 meg mystery.
That would square with glibc hanging on to it - the memory is not
allocated to anything but is part of the free space in the malloc
heap show will not show up as leaked memory or as still allocated
memory because it isn't.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|