Speicherleck C++

Ich habe gerade einen Code in C++ geschrieben, der einige String-Manipulationen durchführt, aber als ich Valgrind überlief, zeigte es einige mögliche Speicherlecks. Beim Debuggen des Codes auf granularer Ebene habe ich ein einfaches C++-Programm geschrieben, das wie folgt aussieht:

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

und wenn ich valgrind darüber laufen lasse, bekomme ich:

==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

Dann fiel mir auf, dass wir zwangsweise beendet wurden (was ich auch in meinem ursprünglichen C++-Code durchgeführt habe). Jetzt ist das Problem, dass ich das Programm beenden möchte, da mein vorheriger alter Code auf den Beendigungsstatus des neuen Codes wartet. Für zB binär wartet a.out auf den Exit-Status von b.out. Gibt es eine Möglichkeit, die Speicherlecks zu vermeiden, oder sollte ich mir wirklich Sorgen um die Speicherlecks machen, da das Programm zu diesem Zeitpunkt bereits beendet wird?

Dies wirft für mich auch eine andere Frage auf, ist ein solcher Code schädlich?

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

Use return 0; instead of exit(0); at the end of main. The use of exit circumvents the execution of the destructors.

If you insist on using exit():

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

Also, when you return from main the returned value becomes the application’s exit code. So if you want to pass an exit code, use return exitCode; in main() instead of exit.

Regarding that part:

This also raise another question for me, is such a code harmful?

Yes, because it is a BAD programming habit.

The OS will clean up any memory you failed to release, so as long as you haven’t managed to eat all system memory and the page file, you shouldn’t damage the OS.

However, writing sloppy/leaky code might turn into habit, so relying on the OS for cleaning up your mess is a bad idea.

This also raise another question for me, is such a code harmful?

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

It’s not harmful on modern operating systems, because they will close all resources owned by a process automatically when the process ends.

However, it’s still bad practice, and might lead to subtle and hard to find errors when, over several years of maintenance, the code slowly changes until, on day, this does become harmful. I have worked in projects where some of the code was a decade old and I have learned a few lessons doing so, some of them rather harsh. Therefore, I would avoid writing such code, even if it currently doesn’t pose a problem.

In most cases, it’s worth cleaning up after yourself, for the many good reasons already given: better maintainability, better utility from checking tools and so on.

If there are other functional reasons to clean up, maybe your data is saved to a persistent store, then you have no choice – you must clean up (although you might want to reconsider your design).

In some cases however, it may be better to just exit and “leak”.

At the end of a program, your process is going to exit. When it does so, the operating system will recover any memory allocated by your program and in some cases it can do this much more quickly.

Consider a large linked list, where each node is dynamically allocated, and carries a substantial dynamically allocated structure. To clean this up you must visit each node and release each payload (which in turn may cause other complex structures to be walked).

You may end up performing millions of memory operations to run through such a structure.

The user wants to exit your program, and they sit there for 10s of seconds waiting for a bunch of junk processing to happen. They cannot possibly be interested in the result – they’re quitting the program after all.

If you let this “leak”, the operating system can reclaim the entire block of memory allocated to your process much more quickly. It doesn’t care about the structures and any object cleanup.

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

Ultimately you must understand what your tools are telling you, to be sure you’re using them properly.

To avoid the memory leak, return the status from main instead of calling exit. If you’re returning zero, you can omit the return statement if you like; the program will exit with a status of zero in that case.

This also raise another question for me, is such a code harmful?

On a modern operating system, it won’t cause any harm – all resources are reclaimed automatically when a program terminates. However, it does make it harder to use tools like Valgrind to find genuine problems, so it’s best to avoid even harmless memory leaks if you can.

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

At the time your process is actually exiting, as when main() exits, the OS will reclaim all resources allocated to your application either way. How you exit isn’t so important – at least with regard to dynamic memory.

If you have some distributed database connection open or something, you should use atexit() handlers to close it, and forceful termination with straight-up exit may make them not run which would be bad – but as far as your OS resources are concerned you’re probably okay.

You should also always make sure you release (manual) file locks and similar things as they may not go away due to a process exit.