This is the mail archive of the libc-help@sourceware.org mailing list for the glibc 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]

Re: Huge chunks of anonymous memory


On 11 Jul 2008, Vinu Rajashekhar verbalised:
> I could see around 25 Mb being allocated in total and all that is
> part of the heap, these large chunks of 50-60Mb weren't done through
> malloc or mmap.

Strange.

> Here's some more info - the files I add to glibc are in C++ and they use calls
> to the nptl library, I mean they make use of pthread_create and
> pthread_mutexes and
> stuff even though I am instrumenting into the nptl library. So I am guessing
> that this memory is set up during library load or something and there is
> some problem in the way I am linking stuff right now, maybe there is something
> special I need to do because of adding C++ files to glibc.

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

> Instead of building the files along with glibc build, I tried building
> a shared library with my source code and then linking it to glibc
> during glibc build, still the memoy trouble persists. Any help or clue
> will be helpful. If any more info is needed please ask for it.

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

> PS: One more thing, when I use mtrace and muntrace() in my process linked
> with the new glibc or add these two functions in the global constructor and
> destructor in the C++ code, memory consumption is reduced from 150 Mb to 15 Mb
> but the lock performance is reduced from 25000 locks/s to 4000 locks/s.

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


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