Linux and memory leaks

Question

Does Linux automatically re-claim all memory used by an applications immediately?

If so then should the application really bother about freeing all memory before exit?

Is it really worth to call the destructor of every class in a multi-threading application before making a call to exit(0)?

If Linux always re-claims all memory used by an application immediately, then memory leaks are only the dangling pointers which the application has created and that too only it its lifetime.

Answer 1

Does Linux automatically re-claim all memory used by an applications immediately?

No, but yes in the sense that you're implying. All virtual memory belonging to the process are released. Frames that aren't shared are made available to other processes.

If so then should the application really bother about freeing all memory before exit?

Yes, for several reasons:

• You may decide to extend the code toward other purposes in the future, adding clean-up later on may be difficult.
• You have excessive memory usage, and actually need the virtual memory space being "wasted".
• You need to track down some bugs: Not carefully releasing resources acquired will make debugging very difficult.

There are situations that could arise when not freeing memory is what you want, generally these will be performance related, and only specific to those situations.

Is it really worth to call the destructor of every class in a multi-threading application before making a call to exit(0)?

This is pretty much the same as the last question. Also note that not releasing resources from third party, and OS libraries is effectively the same as not freeing memory.

If Linux always re-claims all memory used by an application immediately, then memory leaks are only the dangling pointers which the application has created and that too only it its lifetime.

Yup. The only time this theory breaks down is when resources held are global, and don't go away at process termination. Shared memory, poorly designed third party libraries, temporary files etc. are examples of these.

Answer 2

It really depends what those constructors do. If all they do is deallocate private memory, no you don't need to.

If they do other things, such as flush disc files which might have unwritten data in them, then it could be important.

I am quite a big fan of the _exit() library call by the way - it's like exit() but the atexit handlers aren't run.

Robust applications should be able to tolerate disappearing at any time, therefore a valid way to quit is _exit(), as it's still more controlled than a crash.

Of course there are other ways of leaking resources - it's not JUST memory. Temporary files is an obvious one - which will keep existing after you call _exit.

Additionally if you create posix or sysv shared memory it keeps existing on process exit. This is really similar to a temporary file (under Linux it's implemented as one on a tmpfs in the kernel)