I have allocated memory using malloc() in embedded Linux (around 10 MB). And checked the free memory it was 67080 kB but even after freeing it using free() it remains the same. It is only after the application is terminated the memory is available again. Does free() not make the freed memory available to the system, if so how to make it available.
-
It depends on the malloc implementation, but often there will be an internal pool, so you may not see any immediate effect from freeing a pointer. – Paul R Jan 29 '14 at 14:31
-
1Possible duplicate: http://stackoverflow.com/questions/5365996/memory-not-freed-after-calling-free – Nemanja Boric Jan 29 '14 at 14:31
-
When you `free` memory the system will still keep it for you in case you need to allocate it again (so it don't have to redo the memory-mapping tables). The system will take the memory when it needs it. – Some programmer dude Jan 29 '14 at 14:32
-
Note that if you are running one of the (decreasingly common) uClinux or otherwise no-MMU embedded Linux configurations, returning memory to the system becomes even more difficult. – Chris Stratton Jan 29 '14 at 16:53
-
@Chris : Yes i am using embedded Linux (customized version similar to uClinux). – Chu Jan 29 '14 at 17:17
-
With or without an MMU? – Chris Stratton Jan 29 '14 at 17:18
-
It has MMU support enabled – Chu Jan 30 '14 at 07:38
4 Answers
free
is a libc library call. it marks heap space as available for reuse. It does not guarantee that the associated virtual mapping will be released. Only after a dirty virtual mapping is released by your OS, then that memory will be system wide free again. This can only happen in chunks of pages.
Also if you allocated memory using malloc
and family and didn't use it then it didn't actually consume physical memory until then - so freeing it will do nothing.

- 21,822
- 5
- 49
- 75
-
Thanks. I need another info.Is there any way we can make the freed memory available to the system from within the application?. – Chu Jan 29 '14 at 14:37
-
@Satchit Only a system call can do that. You would need to manage your memory allocation with `mmap/munmap` manually for that. Also `madvise/MAP_DONTNEED` can do that on a valid mapping. Please note that those system calls will only work with allocations in chunks of system pages. Check `sysconf(SC_PAGESIZE)` for the system page size. – Sergey L. Jan 29 '14 at 14:40
-
I used it like this int* mem = (int*)mmap(NULL, 40960, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_SHARED, -1, 0); retval = munmap(mem, 40960); My page size is 4096 byte. But still not freeing. Should i use mmap differently? – Chu Jan 29 '14 at 15:43
-
@Satchit Have you actually paged that memory in? If you `mmap` memory, but don't use it then it won't be consuming any RAM either. Write something to each page in order to make them dirty. Alternatively pass `MAP_POPULATE` to `mmap`, but that has different behaviour on different OSes. – Sergey L. Jan 29 '14 at 15:47
-
I have used the memory, just initializing it with some values. Actually i am using cat /proc/meminfo to see the free space. – Chu Jan 29 '14 at 15:55
-
@Satchit Try `MAP_PRIVATE`. The kernel may keep shared memory alive. Also double check that it is actually being used in `/proc/self/smaps` – Sergey L. Jan 29 '14 at 16:02
-
@Satchit What did you look at in /proc/meminfo ? MemFree is not useful to look at as it includes filesystem buffers, caches and other stuff. Active(anon) or AnonPages sounds like they could be useful, though I'll have to find some documentation to assess that.. – nos Jan 29 '14 at 17:55
-
If i use mmap along with size above 1 or 2 mb, only then the memory is returned to system(both free mem and active(anon). If the size is of 100 kbs then, the diff. is not shown in freemem but it is visible in active(anon). So thanks that solved the problem. – Chu Jan 31 '14 at 09:21
Does free() not make the freed memory available to the system.
No, usually not.
malloc() normally requests memory from the OS by the low level sbrk()
or mmap()
call. Once assigned to the application, free() just returns the memory to a memory pool that belongs to the application. That is, it's not returned back to the OS for use in another process. (Though some heuristics are in-place to do so in certain circumstances).
If swap space is in place, this becomes less of a problem, the OS will swap out the unused memory of applications to make room for additional physical memory that's required.
if so how to make it available.
Exit the application.
Or you would need to write your own memory allocator that could do this.(which in the general case is not an easy task especially if you don't want to sacrifice overhead and speed).
For a relatively big single piece of 10MB, you could simply request anonymous memory with mmap()
and the memory will be released back to the OS when you munmap()
that piece of memory.

- 223,662
- 58
- 417
- 506
-
I used it like this int* mem = (int*)mmap(NULL, 40960, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_SHARED, -1, 0); retval = munmap(mem, 40960); Still not getting freed to system.. Please suggest. – Chu Jan 29 '14 at 15:30
-
@Satchit It certainly works here, though MAP_SHARED is not needed, use MAP_PRIVATE. You will have a very hard way to determine that 40kb have been returned to the OS though, it just takes a few library calls and suddenly your process might have mapped much more memory (e.g. writing to stdout), and the overall memory statistics will fluctuate more than 40kb. How are you determining that it doesn't work ? Try with the 10Mb you mentioned. Make sure you check that munmap() succeeds. – nos Jan 29 '14 at 18:13
Taken from the malloc 3 man page:
Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3)
You can try to modify the MMAP_THRESHOLD so that by using malloc you are invoking mmap. If you do so, free guarantees that the memory allocated through mmap will return back to the system as soon as you free it.

- 656
- 4
- 11
-
-
While not necessarily related to the observed de-allocation behavior, it's worth noting that an embedded system is not necessarily using glibc, a smaller alternative might or might not have similar allocation behavior. – Chris Stratton Jan 29 '14 at 16:50
Your malloc() calls obtain memory from the system, and maintain a heap data structure for keeping track of used and free memory within the process. Your free() calls return memory to the heap, where they are marked free, but they're still part of the process's memory.
If you want memory deallocation to return pages to the system, you'll have to write your own memory manager, but keep in mind that it'll only be able to completely free memory under the right conditions: It depends on the behavior of your application, whether your allocations and deallocations span page boundaries and cleanly de-fragment, etc. You need to understand the memory allocation behavior of your application to know whether this will be any benefit.

- 5,790
- 3
- 25
- 36