This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: little help with memory leak/management by the glibc 2.3.2?
- From: "Bruce Korb" <bruce dot korb at gmail dot com>
- To: "Steve Munroe" <sjmunroe at us dot ibm dot com>
- Cc: "Jairo Medina" <jairo19 at interhosting dot us>, libc-alpha at sources dot redhat dot com
- Date: Tue, 8 Apr 2008 20:34:31 -0700
- Subject: Re: little help with memory leak/management by the glibc 2.3.2?
On Tue, Apr 8, 2008 at 12:22 PM, Steve Munroe <sjmunroe@us.ibm.com> wrote:
> jairo19@interhosting.us wrote on 04/08/2008 01:41:07 PM:
>
> > Hola:
> >
> > This demo program I wrote shows how much memory the process is using (as
> > given by the kernel /proc/self/status interface) before and after I
> > request and free memory.
> >
> > So the issue is that as I request and free memory of different sizes,
> > the process seems not to relinquish the full amount of requested memory.
> > My real world program seems to have a small loss of approx 100Kb for
> > almost each memory request/release cycle, and it needs to do this 500000
> > times, so you can imagine that I am running out of memory, but the
> > program is releasing all the memory it asks for. In both cases valgrind
> > does not report any leaks.
> >
>
> Working as designed. You can read about malloc's internal design by reading
> the comments in the source:
>
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c?cvsroot=glibc
>
> You may be able to adjust things more to your liking using the mallopt
> interface:
>
> http://www.gnu.org/software/libc/manual/html_mono/libc.html#Malloc-Tunable-Parameters
Despite this being a development list, I also am having a little problem.
It seems that on an occasional basis another 128K gets anonymously mapped
into my address space with an extra 896K mapped as unreadable and unwritable.
It would not be so bothersome, except that eventually allocations
fail. And, no,
it is not due to failing to "free()" the space. It seems as if the
memory is filled
with some sort of malloc pointer spaghetti