public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/10756] New: free doesn't free all memory alloced by memalign
@ 2009-10-11 14:57 phil dot pratt dot szeliga at gmail dot com
  2009-10-11 15:04 ` [Bug libc/10756] " phil dot pratt dot szeliga at gmail dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: phil dot pratt dot szeliga at gmail dot com @ 2009-10-11 14:57 UTC (permalink / raw)
  To: glibc-bugs

free doesn't free all memory alloced by memalign.  This is causing my
program to run out of memory, even though I am freeing old memory.
This bug exists in newlib too.

code example:
=======================================
#include <malloc.h>
#include <stdio.h>

static void printMemUsage()
{
 struct mallinfo mi;
 mi = mallinfo();
 printf("MemUsage: %d\n", mi.arena);
}

int main(unsigned long long spe_id, unsigned long long
program_data_ea, unsigned long long env)
{
 printMemUsage();
 void * dyn_mem = memalign(16, 65535);
 printMemUsage();
 free(dyn_mem);
 printMemUsage();
 return 0;
}
=====================================
compile with:
gcc main.c
=====================================
run:
#./a.out
MemUsage: 0
MemUsage: 200704
MemUsage: 135168
#

-- 
           Summary: free doesn't free all memory alloced by memalign
           Product: glibc
           Version: 2.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: phil dot pratt dot szeliga at gmail dot com
                CC: glibc-bugs at sources dot redhat dot com


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/10756] free doesn't free all memory alloced by memalign
  2009-10-11 14:57 [Bug libc/10756] New: free doesn't free all memory alloced by memalign phil dot pratt dot szeliga at gmail dot com
@ 2009-10-11 15:04 ` phil dot pratt dot szeliga at gmail dot com
  2009-10-12  1:15 ` a_llison_life at yahoo dot com
  2009-10-12  6:58 ` pasky at suse dot cz
  2 siblings, 0 replies; 4+ messages in thread
From: phil dot pratt dot szeliga at gmail dot com @ 2009-10-11 15:04 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From phil dot pratt dot szeliga at gmail dot com  2009-10-11 15:04 -------
(In reply to comment #0)

Oops.  the main line should be "int main(int argc, char * argv)" as usual.
This code originally came from the Cell BE Processor.

> free doesn't free all memory alloced by memalign.  This is causing my
> program to run out of memory, even though I am freeing old memory.
> This bug exists in newlib too.
> 
> code example:
> =======================================
> #include <malloc.h>
> #include <stdio.h>
> 
> static void printMemUsage()
> {
>  struct mallinfo mi;
>  mi = mallinfo();
>  printf("MemUsage: %d\n", mi.arena);
> }
> 
> int main(unsigned long long spe_id, unsigned long long
> program_data_ea, unsigned long long env)
> {
>  printMemUsage();
>  void * dyn_mem = memalign(16, 65535);
>  printMemUsage();
>  free(dyn_mem);
>  printMemUsage();
>  return 0;
> }
> =====================================
> compile with:
> gcc main.c
> =====================================
> run:
> #./a.out
> MemUsage: 0
> MemUsage: 200704
> MemUsage: 135168
> #



-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/10756] free doesn't free all memory alloced by memalign
  2009-10-11 14:57 [Bug libc/10756] New: free doesn't free all memory alloced by memalign phil dot pratt dot szeliga at gmail dot com
  2009-10-11 15:04 ` [Bug libc/10756] " phil dot pratt dot szeliga at gmail dot com
@ 2009-10-12  1:15 ` a_llison_life at yahoo dot com
  2009-10-12  6:58 ` pasky at suse dot cz
  2 siblings, 0 replies; 4+ messages in thread
From: a_llison_life at yahoo dot com @ 2009-10-12  1:15 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From a_llison_life at yahoo dot com  2009-10-12 01:15 -------
http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html#Freeing-after-Malloc

The description of free says "Occasionally, free can actually return memory to
the operating system and make the process smaller. Usually, all it can do is
allow a later call to malloc to reuse the space. In the meantime, the space
remains in your program as part of a free-list used internally by malloc."

So, your test program is not proving a bug, it is just showing that in this
case, not all the space allocated by memalign's call to malloc was released from
the process. 

Try running this enhanced test program to show the difference:
#include <malloc.h>
#include <stdio.h>

static void printMemUsage()
{
 struct mallinfo mi;
 mi = mallinfo();
 printf("MemUsage Arena: %d\n", mi.arena);
 printf("MemUsage Fordblks: %d\n", mi.fordblks);
 printf("=============================\n");
}

int main(int argc, char **argv)
{
 printf("Memory Usage at program start\n");
 printMemUsage();
 void * dyn_mem = memalign(16, 65535);
 printf("Memory Usage after memalign\n");
 printMemUsage();
 free(dyn_mem);
 printf("Memory Usage after free of memory allocated by memalign\n");
 printMemUsage();
 void * more_mem = malloc(168);
 printf("Memory Usage after another malloc\n");
 printMemUsage();
 free(more_mem);
 printf("Memory Usage after free of the memory allocated by the second
allocation\n");
 printMemUsage();
 return 0;
}

The fordblks member of the mallinfo struct describes how much free heap space is
maintained by malloc on its free list
(http://www.gnu.org/s/libc/manual/html_node/Statistics-of-Malloc.html)

So, that extra memory you are seeing is not a memory leak.  The next time you
request memory with malloc, that memory can be used.

This output demonstrates this behavior:

Memory Usage at program start
MemUsage Arena: 0
MemUsage Fordblks: 0
=============================
Memory Usage after memalign
MemUsage Arena: 200704
MemUsage Fordblks: 135144
=============================
Memory Usage after free of memory allocated by memalign
MemUsage Arena: 135168
MemUsage Fordblks: 135168
=============================
Memory Usage after another malloc
MemUsage Arena: 135168
MemUsage Fordblks: 134992
=============================
Memory Usage after free of the memory allocated by the second allocation
MemUsage Arena: 135168
MemUsage Fordblks: 135168
=============================


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/10756] free doesn't free all memory alloced by memalign
  2009-10-11 14:57 [Bug libc/10756] New: free doesn't free all memory alloced by memalign phil dot pratt dot szeliga at gmail dot com
  2009-10-11 15:04 ` [Bug libc/10756] " phil dot pratt dot szeliga at gmail dot com
  2009-10-12  1:15 ` a_llison_life at yahoo dot com
@ 2009-10-12  6:58 ` pasky at suse dot cz
  2 siblings, 0 replies; 4+ messages in thread
From: pasky at suse dot cz @ 2009-10-12  6:58 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From pasky at suse dot cz  2009-10-12 06:58 -------
Just to note, if it would cause your program to actually grow its memory usage
indefinitely, i.e. the freed memory wouldn't be reused in future mallopt()
calls, that would indeed be bug. But I don't see that being a case, putting a
simple while (1) loop around the mallopt()-free().

I don't think relying on functions like this to behave responsibly in such a
memory-tight environment like the SPU is reasonable. Actually, I haven't done
much SPU programming but from what I know I'm not sure if calling malloc from
the SPU context makes any sense whatsoever...

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-10-12  6:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-11 14:57 [Bug libc/10756] New: free doesn't free all memory alloced by memalign phil dot pratt dot szeliga at gmail dot com
2009-10-11 15:04 ` [Bug libc/10756] " phil dot pratt dot szeliga at gmail dot com
2009-10-12  1:15 ` a_llison_life at yahoo dot com
2009-10-12  6:58 ` pasky at suse dot cz

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