C ++ memory leak

Question

I just wrote C ++ code that does some string manipulation, but when I ran valgrind it shows some possible memory leaks. Debugging code to the granular level I wrote a simple C ++ program that looks like this:

#include<iostream> #include<cstdlib> using namespace std; int main() { std::string myname("Is there any leaks"); exit(0); } 

and running valgrind over it, I got:

 ==20943== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 26 from 1) ==20943== malloc/free: in use at exit: 360,645 bytes in 12,854 blocks. ==20943== malloc/free: 65,451 allocs, 52,597 frees, 2,186,968 bytes allocated. ==20943== For counts of detected errors, rerun with: -v ==20943== searching for pointers to 12,854 not-freed blocks. ==20943== checked 424,628 bytes. ==20943== ==20943== LEAK SUMMARY: ==20943== definitely lost: 0 bytes in 0 blocks. ==20943== possibly lost: 917 bytes in 6 blocks. ==20943== still reachable: 359,728 bytes in 12,848 blocks. ==20943== suppressed: 0 bytes in 0 blocks. ==20943== Reachable blocks (those to which a pointer was found) are not shown. ==20943== To see them, rerun with: --show-reachable=yes 

Then it seemed to me that we were forced to exit (which I also performed in my C ++ source code). Now the problem is that I want to exit the program, since my previous old code is waiting for the exit status of the new code. For example, the a.out binary is awaiting the exit status of b.out. Is there a way to avoid memory leaks, or do I really need to worry about a memory leak, since the program is already exiting from this point.

This also begs me another question, is such code harmful?

 #include<stdio.h> #include<cstdlib> int main() { char *p=(char *)malloc(sizeof(char)*1000); exit(0); } 

Answer 1

If you insist on using exit() :

 #include<iostream> int main(){ { std::string myname("Are there any leaks?"); } exit(0); } 

In addition, when returning from main return value becomes the application exit code. Therefore, if you want to pass an exit code, use return exitCode; in main() instead of exit .

Regarding this part:

This also begs me another question, is such code harmful?

Yes, because it is a habit of programming BAD .

The OS will clear any memory that you could not release, so until you have time to eat all the system memory and the page file, you should not damage the OS.

However, writing a messy / leaky code can become a habit, so relying on the OS to clean up your mess is a bad idea.

Answer 2

Use return 0; instead of exit(0); at the end of main . Using exit bypasses the execution of destructors.

Answer 3

This also begs me another question, is such code harmful?

 #include<stdio.h> int main() { char *p=(char *)malloc(sizeof(char)*1000); exit(0); } 

This is not harmful to modern operating systems, since they automatically close all resources belonging to the process when the process ends.

However, this is still bad practice, and can lead to subtle and difficult to find errors when the code slowly changes over the course of several years of maintenance until it becomes harmful a day. I worked on projects where some of the code was a decade ago, and I learned a few lessons, some of them pretty harsh. Therefore, I would not write such code, even if it currently does not pose a problem.

Answer 4

In most cases, it is worth cleaning it after yourself, for many already justified reasons: improved maintainability, the best utility from verification tools, etc.

If there are other functional reasons for cleaning, it is possible that your data is stored in persistent storage, then you have no choice - you should clear it (although you can revise your design).

In some cases, however, it may be better to just go out and "leak."

At the end of the program, your process will be completed. When this happens, the operating system will recover any memory allocated by your program, and in some cases it can do it much faster.

Consider a large linked list where each node is dynamically allocated and carries a substantial dynamically distributed structure. To clear this, you must visit each node and release each payload (which, in turn, can lead to the passage of other complex structures).

You can perform millions of memory operations to perform such a structure.

A user wants to exit your program, and they sit there for 10 seconds, waiting for a bunch of unwanted processing to happen. They may not be interested in the result - they still leave the program.

If you allow this "leak", the operating system can quickly return the entire memory block allocated to your process. He does not care about the structures and cleaning of any object.

http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx

Ultimately, you must understand what your tools tell you to make sure that you use them correctly.

Answer 5

To avoid a memory leak, return the status from main instead of calling exit . If you return zero, you can omit the return if you want; the program will exit with a status of zero in this case.

This also begs me another question, is such code harmful?

In a modern operating system, this will not cause any harm - all resources will be fixed automatically when the program ends. However, this makes it difficult to use tools like Valgrind to find real problems, so it's best to avoid even harmless memory leaks if you can.

Answer 6

 #include<iostream> using namespace std; int main() { { std::string myname("Is there any leaks"); } exit(0); } 

Answer 7

At the time when your process actually ends, as when main () exits, the OS will restore all the resources assigned to your application in any case. How you exit is not so important - at least with regard to dynamic memory.

If you have some kind of distributed connection to the database open, you should use atexit () handlers to close it, and forcing with direct exit may cause them not to start, which would be bad, but regarding the resources of your OS that you probably all right.

You should also always ensure that you open (manually) file locks and other similar things, as they may not disappear due to exiting the process.

Answer 8

If you want to break the execution and pass the return code without exceeding the destructors, throw an exception and extract the return value from the exception in main() .

Answer 9

If the program exits, you do not need to worry about the memory that was allocated using malloc or new . The OS will take care of this - the virtual address space of everything in your process will exclusively go away when the process dies. If you use shared memory or named pipes, this can still be a problem.

Answer 10

To add another opinion.

Such a code is not harmful to everyone. The OS will take care of everything when the process ends. Everything else leads to an unstable OS. Just make sure your persistent data (files, ...) are consistent.

To go a little further and provocatively states that explicitly freeing memory when exiting a program can be harmful.

• Exiting the program takes longer (have you ever been annoyed waiting for the program to exit until the computer shuts down?)
• The correct destruction order is not always trivial, especially with third-party components (I remember some programs that probably crash on exit)
• OS cannot let you free memory after exiting main (*) and kill your program instead

Do you risk this only so that Valgrind gives you a certain result? (**)

---

(*)

 #include<iostream> using namespace std; std::string myname("Is there any leaks"); int main() { exit(0); } 

(**) Well, of course, the output of any memory analyzer is more useful without noise. As for the explicit freeing of memory when exiting in debug mode?