public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sakovacs at freemail dot hu" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/2531] New: missing call or documentation for malloc_trim() ... Date: Sun, 09 Apr 2006 08:53:00 -0000 [thread overview] Message-ID: <20060409085351.2531.sakovacs@freemail.hu> (raw) Let me describe my issue and you can decide whether it is a bug in libc or just missing documentation on the man pages. I've spent a couple of weeks debugging my program, it processed big files and allocated lots of small memory blocks in the process, free()'d the memory afterwards and RSS still didn't decrease. I obviously thought it was a memory leak, valgrinded, etc, until I came down to this very simple program: #include <unistd.h> #include <malloc.h> int main(int argc, char *argv[]) { int max = 10000000; char** p1 = (char**) malloc(max * sizeof(char*)); for (int x = 0; x < max; x++) { p1[x] = (char*) malloc(29); } for (int x = 0; x < max; x++) { free(p1[x]); } free(p1); usleep(20000 * 1000); // so that we have time to check the RSS.. return 0; } This program runs up to ~500Mb on my system, and even after free()'ing the RSS does not shrink. I think for most of you it is obvious now, that the issue is that free() does not return memory to the system. Unfortunately on the man page there is no reference to this behaviour, also no reference to malloc_trim() call that can return some of the memory (depending on the fragmentation). In this example code, if you call malloc_trim(0) right before the usleep() the RSS goes back to less than 1M (this is a simple case, no fregmentation, all memory could be returned to the OS). Now, I know that malloc_trim() does not guarantee the return of any memory, but I would think that A) the linux free() implementation should call it from time to time (based on the allocated/free memory ratio?.. I'm not the proper person to define such an algorithm) B) the man pages should contain the fact that free() never returns allocated pages to the OS and that on linux malloc_trim() call can be used to try to return pages. I just would like to avoid others spending hours debugging their programs while there is nothing to debug. Looking forward to hear your opinion, Cheers, Sandor -- Summary: missing call or documentation for malloc_trim() ... Product: glibc Version: 2.3.5 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: sakovacs at freemail dot hu CC: glibc-bugs at sources dot redhat dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=2531 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
next reply other threads:[~2006-04-09 8:53 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-04-09 8:53 sakovacs at freemail dot hu [this message] 2006-04-09 8:55 ` [Bug libc/2531] " sakovacs at freemail dot hu 2006-04-26 2:15 ` drepper at redhat dot com 2006-04-26 11:35 ` sakovacs at freemail dot hu 2006-05-01 18:41 ` drepper 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=20060409085351.2531.sakovacs@freemail.hu \ --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: linkBe 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).