Dynamically Allocated Memory After Program Termination

dynamically allocated memory after program termination

I don't think that there are any guarantees in the language standard, but modern operating systems which support sparse virtual memory and memory protection (such as MacOS X, Linux, all recent version of Windows, and all currently manufactured phone handsets) automatically clean up after badly-behaved processes (when they terminate) and free the memory for you. The memory remains unavailable, however as long as the program is running.

If you're programming on microcontrollers, on MacOS 9 or earler, DOS, or Windows 3.x, then you might need to be concerned about memory leaks making memory permenantly unavailable to the whole operating system.

When a program terminates what happens to the memory allocated using malloc that is not free'ed?

The other answers tell you the two important things:

  1. Yes, the memory is reclaimed by the OS, so you don't technically need to free() it.
  2. It's good practice to free everything you malloced anyway.

However, it's important to say why it's good practice to free() everything you've malloced. In my view:

  1. Habit: If you get in the habit of freeing whenever you've malloced, you won't accidentally forget when a memory segment isn't around for the lifetime of the program.
  2. Maintainability: If someone comes along to refactor your program so that a segment of memory is no longer around for the lifetime of the program, the presence of cleanup code in the original will mean that it's very likely that the refactored version also includes the cleanup code. For me, this is the most important reason.
  3. Debugging: If we expect that all memory is cleaned up correctly, then spotting memory that's actually leaking is much easier.

Does memory allocated in a function still stay allocated after the function returns?

I assume, although the function "f1" has terminated, the allocated char array still stays allocated until the main program terminates completely.

True. Dynamically allocated memory has nothing to do with functions, it belongs to process.

That is, the allocated memory still belongs to the main and no other process can access it from outside. Am I right?

Memory doesn't belong to main() (intended as function) but to process itself (of which main() is just the entry point). In a system with memory protection (where each process is isolated from the others) it's not accessible from outside. You can, however, allocate it in a system specific way to share memory across processes.

Do I have to free the array (allocated in "f1") before the program terminates (or does it get freed as soon as the main program terminates) ?

Yes. Unallocated memory - in most systems - is automatically deallocated by Operating System when process terminates but this is system dependant. IMO even when OS does it you should always deallocate, using such automatic deallocation as a red flag (I forget that to deallocate, is it a bug? something I missed?). Moreover if f1 is invoked 1000 times it'll leak memory each time quickly eating all available memory. Think about a process in a server, it may (and should) be up and running for years.

If the answer for the second question is "yes" then how do you free an array allocated in another function?

It's nice when who allocates memory also frees it. If it's not possible then caller will become responsible for such memory. It's, for example, what strdup() does. In such case called function must return (somehow) a pointer to allocated memory (or an handle/token that can be used by another specialized function). For example:

char* pBuffer = f1();
// Use it
free(pBuffer);

Note that there are many many techniques if you want to hide such internal pointer. You may use a token (for example an integer, key in a dictionary), a typedef or an opaque type.



Related Topics



Leave a reply



Submit