This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Huge chunks of anonymous memory
- From: "Vinu Rajashekhar" <vinutheraj at gmail dot com>
- To: Nix <nix at esperi dot org dot uk>
- Cc: libc-help at sourceware dot org
- Date: Sat, 12 Jul 2008 00:04:36 +0200
- Subject: Re: Huge chunks of anonymous memory
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bQPshMPdWlRa5qC+ztenAJG++ESUURbd+vdFz3fe774=; b=JHSqrIl+ZzzD8KL/9USR2idMW4SLWlReuu3yMnL3pgt4sh+12A+oiu4spal0ArZqbC V9GosAiWK/lrz3qCNJILKcbxLrtrrdJ8HiDeZNX+qZYPj8fz05sHNNLqFlHmlgvQYjbu EacFCDpE9PLRh6FuTZFagz92+kGn8HztRmrAg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Gf/fgjgo4DYt67Qjl2XHwrUu18p2x4kzxKAv06pCmzb6aCIBCGx2M3TYQXbgGpyudH Om8cl+jqdNIipcjoxVk58sglGapL933Yxyum/06T8/zUaCOQMLjsa1G9FwEk/5Ku0ZIh 4Of0YHg8sRBIIA8Q0WdgpScKdKg26HacBhewY=
- References: <c81a07350807091426q62889968r69ea4b56f440d2c@mail.gmail.com> <87zloocclg.fsf@hades.wkstn.nix>
Hi,
Yea I tried that and MMAP_MAX_ stuff too,
those anonymous allocations I dont think were done
through mmap or malloc coz I tried running strace and I also
did gdb debugging with breakpoints on mmap and malloc.
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.
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.
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.
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.
Cheers,
Vinu
On Fri, Jul 11, 2008 at 11:52 PM, Nix <nix@esperi.org.uk> wrote:
> On 9 Jul 2008, Vinu Rajashekhar told this:
>
>> Hi,
>> Sorry I forgot to give some information.
>>
>> Basically this anonymous memory is not part of the heap or stack
>> coz I used valgrind to check memory and its causing my RSS (resident set
>> size to go beyond 100 MB). Here is the output from pmap
>
> Big allocations with glibc malloc are normally satisfied via mmap().
>
> You could try turning mmap() allocation off by setting the
> MALLOC_MMAP_THRESHOLD_ environment variable to 0 before starting your
> program, and looking at the maps again: if those anonymous blocks are
> gone and the heap is bigger, the memory usage is attributable to
> malloc(). (libstdc++'s default operator new satisfies allocation
> requests through malloc().)
>
> It's probably just an ordinary memory leak.
>