Re: Huge chunks of anonymous memory

["Vinu Rajashekhar" <vinutheraj at gmail dot com>]

On Sat, Jul 12, 2008 at 12:44 AM, Nix <nix@esperi.org.uk> wrote:
> On 11 Jul 2008, Vinu Rajashekhar verbalised:
>
> Strange.
Well its strange because the same instrumentation, I mean absolute same source
code on the FreeBSD libthr(their threading library) gives memory
consumption (here I mean
Resident set size) of 5 - 16 Mb nothing more.
>
>
> Well, when are you allocating memory? Is this instrumentation stuff that
> kicks in at library load time, or later? (From the glibc
> memory-allocation perspective, C++ stuff is just C stuff; are you using
> static globals and relying on order of construction or something like
> that?)

I use vectors and hashmaps in the C++ code and I checked it using
valgrind memcheck and massif, all these allocations are being done and after
that the heap goes into maximum 25 Mb, so I dont know how my RSS can be 100 Mb!!

Yea I use a static global which goes to dynamically allocate other
class objects and stuff
and I create a thread and use mutexes. All this is using the nptl API,
but I add this code to
nptl source and create a new glibc. So is there some problem in
linking which might occur ?
>
>
> Well, if you want to figure out where the mmap()s are coming from, why
> not start gdb and break on `mmap'? (That works for me here, at least.)
>
Yea I just mentioned that I tried that and many other things, these 50Mb
and 60Mb chunks aren't allocated through any mmap or malloc, or there
might a problem with memory alignment or something.

>
> Hm. Using C++ constructors and destructors inside the glibc source tree
> is liable to be somewhat fraught. I'm not sure anyone's tried it
> before. (I can't immediately see anything fundamental stopping it
> working, though, and that you're only eating heaps of memory and not
> crashing indicates that it mostly *is* working...)
>
Yea its not crashing, everything is working well just for the memory hog,
the thing eats up too much memory.

As I said before if I use the mtrace and muntrace functions any process linked
with the instrumented glibc or in the C++ src code, then memory usage
comes down but performance suffers.

Cheers,
Vinu