3

I have two related questions hence I am asking them in this single thread.

Q1) How can I confirm if my OS is clearing un-"free"'ed memory (allocated using malloc) automatically when a program terminates? I am using Ubuntu 11.04, 32-bit with gcc-4.5.2

As per a tutorial page by Steven Summit here, "Freeing unused memory (malloc'ed) is a good idea, but it's not mandatory. When your program exits, any memory which it has allocated but not freed should be automatically released. If your computer were to somehow ``lose'' memory just because your program forgot to free it, that would indicate a problem or deficiency in your operating system."

Q2) Suppose, foo.c mallocs a B-bytes memory. Later on, foo.c frees this B-bytes memory locations and returns it to the OS. Now my question is, can those PARTICULAR B-bytes of memory locations be re-allocated to foo.c (by the OS) in the current instance OR those B-bytes can't be allocated to foo.c untill its current instance terminates ?

EDIT : I would recommend everyone who reads my question to read the answer to a similar question here and here. Both answers explain the interaction and working of malloc() and free() in good detail without using very esoteric terms. To understand the DIFFERENCE between memory-management tools used by kernel (e.g. brk(), mmap()) and those used by the C-compiler (e.g. malloc(), free()), this is a MUST READ.

Community
  • 1
  • 1
Abhinav
  • 1,882
  • 1
  • 18
  • 34

4 Answers4

2

Most Modern OS will reclaim the allocated memory so you need not worry about that.
The OS doesn't understand if your application/program leaked memory or not it simply reclaims what it allocated to an process once the process completes.

Yes freed memory can be reused(if needed) & the reuse can happen in the same instantiation.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • Is there any practical way of confirming this, say a test software I can make or may be directly use ? – Abhinav Apr 25 '12 at 07:45
  • @Abhinav: Fortunately, that overhead is not needed. You just need to refer the doccumentation of your target OS and it should doccument the behavior. – Alok Save Apr 25 '12 at 07:50
  • @Abhinav, confirming which part? You can't confirm that the OS is reclaiming process memory without instrumenting the OS, which is going to slow its memory management down and will be very difficult for you to decipher in a modern OS with a unified page cache. For process memory reuse, take a look at http://valgrind.org/. – geekosaur Apr 25 '12 at 07:52
2

When a process ends either thru a terminating signal, e.g. SIGSEGV, or thru the _exit(2) system call (which happens to be called also when returning from main), all the process resources are released by the kernel. In particular, the process address space, including heap memory (allocated with mmap(2) (or perhaps sbrk(2)) syscall (used by malloc library function) is released.

Of course, the free library function either (often) makes the freed memory zone reusable by further future calls to malloc or (occasionally, for large memory zones) release some big memory chunk to the kernel using e.g. munmap(2) system call.

To know more about the memory map of process 1234, read sequentially the /proc/1234/maps pseudo-file (or /proc/self/maps from inside the process). The /proc file system is the preferred way to query the kernel about processes. (there is also /proc/self/statm and /proc/self/smaps and many other interesting things).

The detailed behavior of free and malloc is implementation dependent. You should view malloc as a way to get heap memory, and free as a way to say that a previously malloc-ed zone is useless, and the system (i.e. standard C library + kernel) can do whatever it wants with it.

Use valgrind to hunt memory leak bugs. You could also consider using Boehm's conservative garbage collector, i.e. use GC_malloc instead of malloc and don't bother about freeing manually memory.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Thanks for a satisfactory answer. I suppose the /proc/foo/ directory will exist as long as the program foo.c is running. Right? So, in that case, how can I the corresponding maps file? Although I did check the maps file of some running pids (e.g. chrome) and it threw at me a bunch of amazing information at me. I am astonished . :) – Abhinav Apr 25 '12 at 07:53
  • I'm not sure to understand your question (don't forget that executables and processes are not the same; a given program has one executable e.g. `/bin/bash` for your shell, but can be running in several processes). `/proc/1234/` exists only as long as process 1234 exists. (It is a pseudo-file, not on the disk, so reading it is quick). From inside that process, `/proc/self/` is a symlink to it. – Basile Starynkevitch Apr 25 '12 at 08:03
  • Thumbs up for the valgrind and Boehm's links. – Abhinav Apr 25 '12 at 08:44
1

Q1. You just have to assume that the operating system is behaving correctly.

Q2. There is no reason why the bytes can't be reallocated to foo.c it just depends on how the memory allocation routines work.

Nick
  • 25,026
  • 7
  • 51
  • 83
1

Q1) I'm not sure about how you can confirm. However, about the second paragraph, it's considered good style to always free whatever memory you allocate. A good explanation of this is found here: What REALLY happens when you don't free after malloc?.

Q2) Definitely; those bytes are usually the first to be reallocated (depending on the malloc implementation). For a great explanation, see: How do malloc() and free() work?.

Community
  • 1
  • 1
rainbowsprinkles
  • 257
  • 5
  • 11
  • The second link has a really amazing answer. (http://stackoverflow.com/a/1119334/842808) – Abhinav Apr 25 '12 at 08:29
  • There is a school of thought that you should not free memory when exiting a program - the argument is that it's like cleaning a house you are moving out of, thats going to be demoloished - it's a complete waste of time and effort. I don't entirely agree, but cannot fault the argument :) – mattnz Apr 25 '12 at 09:01