public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dev at parallels dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug malloc/14581] New: glibc leaks memory and do not reuse after free (leading to unlimited RSS growth)
Date: Fri, 14 Sep 2012 09:41:00 -0000	[thread overview]
Message-ID: <bug-14581-131@http.sourceware.org/bugzilla/> (raw)

http://sourceware.org/bugzilla/show_bug.cgi?id=14581

             Bug #: 14581
           Summary: glibc leaks memory and do not reuse after free
                    (leading to unlimited RSS growth)
           Product: glibc
           Version: 2.15
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dev@parallels.com
    Classification: Unclassified


If you run the program below you will find that it never really allocates more
then 100MB of RAM, while it's RSS grows >700MB (and higher if the internal loop
made longer):

--------------------------
Arena 0:
system bytes     =  759681024
in use bytes     =   75144000
Total (incl. mmap):
system bytes     =  759681024
in use bytes     =   75144000
max mmap regions =          0
max mmap bytes   =          0
---------------------------

The same is confirmed by kernel RSS if allocated memory is touched (below only
VSZ grows as memory is not touched).

Please note, that this program does a VERY simple thing it allocates/frees
objects of 2 fixed sizes only and number of objects is strictly limited, there
is no heap fragmentation if you print virtual addresses of allocated objects
and kernel VMAs, i.e. you will find a huge unused memory extents which are
never reused by glibc. So there is no place for excuses for such behavior like
fragmentation.

Tested on RHEL6.3 (glibc-2.12-1.80.el6_3.5) and on FC16
(glibc-2.14.90-24.fc16.9), FC17 (glibc-2.15).

--------------------------------------
#include <stdio.h>
#include <malloc.h>

#define LSIZE (65536+4096)
#define SSIZE 556
#define NL 500
#define NS 70000

int main(int argc, char **argv)
{
        void * bigalloc[NL];
        void * smallalloc[NS];
        int bptr = 0;
        int sptr = 0;
        int i;

        memset(bigalloc, 0, sizeof(bigalloc));
        memset(smallalloc, 0, sizeof(smallalloc));

        for (i = 0; i < (16*1024*1024*1024ULL)/65536; i++) {
                free(bigalloc[i % NL]);
                free(smallalloc[i % NS]);
                smallalloc[i % NS] = malloc(SSIZE);
                bigalloc[i % NL] = memalign(4096, LSIZE);
        }

        malloc_stats();
        system("ps axv|fgrep stressalloc");
}

--------------------------------------

Linked from https://bugzilla.redhat.com/show_bug.cgi?id=843478

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


             reply	other threads:[~2012-09-14  9:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14  9:41 dev at parallels dot com [this message]
2012-09-14 19:27 ` [Bug malloc/14581] " bugdal at aerifal dot cx
2012-09-15 10:40 ` dev at parallels dot com
2012-09-15 10:44 ` dev at parallels dot com
2012-09-15 12:39 ` bugdal at aerifal dot cx
2012-09-15 14:08 ` bugdal at aerifal dot cx
2012-09-15 21:00 ` bugdal at aerifal dot cx
2012-09-16  9:44 ` dev at parallels dot com
2012-09-16 12:46 ` bugdal at aerifal dot cx
2013-05-13  9:30 ` siddhesh at redhat dot com
2013-05-20 15:12 ` ondra at iuuk dot mff.cuni.cz
2013-05-20 15:39 ` siddhesh at redhat dot com
2014-06-17  4:31 ` fweimer at redhat dot com
2020-04-28 20:05 ` [Bug malloc/14581] memalign allocations are often not reused after free mail at nh2 dot me
2021-11-25 18:05 ` carlos at redhat dot com
2022-08-02 22:20 ` mirh at protonmail dot ch
2022-08-10  4:00 ` carlos at redhat dot com
2022-12-08 14:10 ` nsz at gcc dot gnu.org
2022-12-08 14:47 ` acoplan at gcc dot gnu.org
2022-12-08 16:13 ` carlos at redhat dot com
2022-12-14 21:50 ` dj at redhat dot com
2022-12-15 10:29 ` nsz at gcc dot gnu.org
2022-12-15 10:45 ` nsz at gcc dot gnu.org
2022-12-15 21:44 ` dj at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-14581-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).