I just wrote a code in C++ which does some string manipulation, but when I ran valgrind over, it shows some possible memory leaks. Debugging the code to granular level I wrote a simple C++ program looking like:
#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 struck me that we have forcefully exited (which i performed in my original C++ code as well). Now the problem is that I want to exit from the program as my previous old code waits for the exit status of the new code. For e.g binary a.out waits for the exit status of b.out. Is there any way to avoid the memory leaks, or should i really worry about the memory leaks as the program is already exiting at that point.
This also raise another question for me, is such a code harmful?
#include<stdio.h>
#include<cstdlib>
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.
If you insist on using
exit()
:Also, when you return from
main
the returned value becomes the application’s exit code. So if you want to pass an exit code, usereturn exitCode;
inmain()
instead ofexit
.Regarding that part:
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.
To avoid the memory leak, return the status from
main
instead of callingexit
. If you're returning zero, you can omit thereturn
statement if you like; the program will exit with a status of zero in that case.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.