Why it is necessary to avoid memory leaks in the process of the program is understandable. But why do you need to free the memory of dynamically declared variables before exiting the program?

The only answer that my colleagues and I came up with was that the “zombie” (in Linux), if it appears after the end of the program, takes up minimal space.

In other cases, the OS itself will erase all that was occupied, is not it?

What other negative consequences can occur?

    5 answers 5

    Zombies (in * nix) do not occupy space in the memory (in the sense that you invest in it). It occupies one entry in the scheduler structure in the kernel.

    And so, yes, a normal modern OS (in which almost everyone writes) "everything will erase" behind the process. Almost all. There will be problems with shared memory segments, but this is not automated in the forehead, since deleting or retaining depends on the essence of the application.

    If you suddenly write programs for something else (some self-made monitor for real-time embedded), then you may have to remove the memory yourself.

    • "normal modern OS (in which almost everyone writes)" i. there are / there were operating systems where independent wipe was really important, yes? I would be very grateful if you give an example. - Alexander Romanov
    • @ Alexander Romanov: dos? (Probably.) - VladD
    • @VladD yes indeed. “Thus, programs can be unloaded from memory only in the reverse order of their loading, which imposes a number of restrictions on managing the contents of RAM.” Kolasc.net.ru/cdo/programmes/os/322.htm - Alexander Romanov

    See it. There are no reasons for freeing the memory before the end of the program, except for purely aesthetic ones. The memory will still return to the system after the death of the process.

    However, quite often objects in their destructor perform additional actions. They close the transaction in the database, correctly close the online session, reset the modified data to disk, etc. Thus, if such an object “leaks”, the program will leave something in the incorrect state after completion.

    If your program is small, you can survey it completely, and you are sure that in addition to memory leaks, nothing bad from the missed destructors will happen - you can safely leave memory at the end.

    But if your project is large, then most likely you will not have a complete overview of what module does. In such a situation, it is better to adhere to a disciplined approach and clean up after yourself.

    • 2
      I will add my five kopecks. This may help in finding other errors: the output of valgrind much simpler and clearer when eliminating "optional" errors with unallocated memory that could have been avoided. - LXA
    • 2
      @LXA: Yeah, valgrind tears and tosses on unallocated memory. - VladD

    Before shutting down the program, you need to make sure that the shared resources are released, for example, connections to the database and web servers are closed. Servers for some time may consider your client still connected, which is undesirable. You should reset the data to disk in files if you care about their contents. If you do not care, you can not close - the system will cope on its own.

    Freeing memory is usually unnecessary, even though it is a good tone rule. Moreover, if your program allocated a lot of complex objects in the memory, and the memory partially fell into a swap, then it may be beneficial not to free the memory so as not to force the system to pull information from the disk just to throw it away.

    If you want to quickly complete the process, you can neatly destroy objects that store references to shared resources, and then just kill the process.

    Moreover, ideally, the program should correctly handle the process of killing process at any time. The data should not be damaged. Working out the case of a hard kill process without careful release of memory and resources is an important point when developing programs. Because of this, your program should not cease to be workable (for example, due to corrupted configuration files).

    • one
      Very interesting idea about swap, thanks! - Alexander Romanov
    • "Working out the case of a hard kill process without carefully releasing memory and resources is an important point in developing programs." And what can be done with a hard demolition? By SIGKILL you can fly at any time, and nothing can be done about it. All other cases are not hard but fully processed. - user6550
    • 3
      @klopp: Well, for example, transactional writing to files. With leaving markers for cleanup in case of murder during recording. That is, (1) write to a new file, (2) put a marker, (3) rename an old file to bak (4) rename a new one to an old one (5) delete a marker, (6) check whether markers remain and start to close correctly transaction So no one does, within the experimental error :-) - VladD
    • 3
      @klopp If all programs start to perform at least this "obvious", the world will become much better ... - Athari
    • 2
      So one thing is to take care of YOUR resources, and another thing is about public :) Transactions, files etc - all this refers to “your” data, which if you do not care, then you harm yourself first of all. Caring for the public is much less obvious, IMHO. - user6550
    1. The C code works in places where no operating system can exist at all.
    2. Computer memory is a common resource, extremely complex and expensive to manufacture. Do not think that it belongs to you personally. For example, at the moment on the host from where I am writing you this message is started by 106 processes written by other people (physically they all use DDR for which I personally paid). Imagine what would happen to them if the author of each of them thought only of himself and did not release memory, but on the contrary tried to grab her as much as possible while being obsessed with the idea of ​​the unique and super usefulness of his craft.
    3. The moment of termination of the use of a resource in the program (in particular, memory) may not coincide with its completion.

    But if you write some small application program for a popular OS in which at the same time barely barely 100kB, then you can certainly hope for the OS and the language with automatic garbage collection. In principle, it does not threaten anything, unless of course the program suddenly expands to large sizes and a crowd of users to boot. Then it is definitely worth starting to think more seriously about the distribution of shared resources, in particular, and memory.

    • 1. As a rule, there won't be a memory manager there, so talking about new / malloc in such cases can be avoided. 2. You are absolutely right. In this question we are not talking about leaks accumulated during the work of the program. I completely agree that the program should consume a minimum of memory. - Alexander Romanov

    In C ++, the operators delete and delete[] , with which you free memory, cause object destructors. If there is some logic in the destructor (for example, serialization), it will not work, and some data may be lost. I also note that the free function of the destructor does not call, its task is to free the memory.

    Usually the release of memory is considered good form. Even if you do not have logic in destructors now, this does not mean that it will not appear there in the future (and then you have to shovel the whole project). If your program terminates in this place now, this does not mean that in the future it will not terminate much later (and you will receive a significant memory leak). That is, by clearing the memory, you get fewer problems in the future. The program is becoming more expandable and supported.

    However, it happens that the memory is not specifically released. For example, in C ++ there is a problem with the order of initialization / deinitialization of static variables, which, when detected, is often solved using a singleton. Such a singleton should also exist after the completion of the main function, since after that the static variables are deinitialized. Therefore, it is created using new and is never released.