Jump to content
  • Advertisement
Sign in to follow this  
shurcool

Would this produce a memory leak?

This topic is 3770 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just ran into something I never realized was a problem:
#include <stdlib.h>
#include <list>

int main()
{
    list<int> list1(100, 123); // Create a list with 100 ints with value 123.

    exit(0); // The list ~deconstructor is not called, creating a memory leak!
}

I know that list1 would call new 100 times for each of the ints, and if called, its ~destructor would clean that up. However, since it's on the stack, and I call exit(0) rather than return 0, is its ~destructor even called? According to a simple test I did with my own class, it's not! According to exit() description, it's supposed to "Terminate the process normally, performing the regular cleanup for terminating processes." That doesn't seem to be a normal clean up to me, as it creates memory leaks. Is there any way of using exit() to exit without such side-effects, or is my only way to be sure everything is cleaned up is to call return 0; from main()? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
exit() will perform normal C cleanup, calling atexit() handlers, etc. However, it generally won't perform stack unwind cleanup for C++ objects on the stack.

Share this post


Link to post
Share on other sites
Right.

So my question then is: Is there any safe way to use exit() to exit from within the middle of an application without potentially leaving memory allocated on the stack behind (i.e. creating a memory leak)?

Dynamically allocated memory is not a problem, as I can clean it up myself just before exiting.

If not, what's a good method to self-terminate a program? Is returning from main() the only safe way?

Share this post


Link to post
Share on other sites
Basically, returning from main() is the only way that C++ will guarantee that everything will shut down properly. Specific C++ implementations may have other mechanisms. For example, most C++ implementations will clean up properly if you have an unhandled exception, but it's not guaranteed to work.

Share this post


Link to post
Share on other sites
Okay, I'll adapt my code to have Terminate() set some condition variable like 'running' to false, instead of calling exit() explicitly. That will make the program fall out of the main loop, and eventually get to the bottom of main().

That's probably not the best way though...

Thanks for the help.

Share this post


Link to post
Share on other sites
I don't see the problem if the program is going to exit anyway. To be a leak, the program should still be running.

Share this post


Link to post
Share on other sites
I thought a memory leak was when you exit without deallocating all the memory that you've allocated (usually memory dynamically allocated on the heap, but I don't see why memory allocated on the stack wouldn't count).

Now you've made me unsure, lol. Does an OS have some magical way to restore (i.e. make avaliable for future use; mark as 'free memory') all the memory allocated to a program when it exists, even if that program itself doesn't clean up after itself? I think not... right? But then again, if a program always allocates memory for itself within its own memory space, it *might* be possible...

So what's the scoop on this?

Edit: Wow, apparently that might be true, about the OS forcebly cleaning up after a program terminates. According to wikipedia, anyway:

"In modern operating systems, normal memory used by an application is released when the application terminates. This means that a memory leak in a program that only runs for a short time is rarely serious."

This is starting to make sense along with what I've learned in my OS class. I can't believe I never realized this was the case, until now. Well, I could use more assurance from other people to be completely sure...

Does that make it safe to exit() while leaving allocated memory behind?

Wow, I can't believe how one's world, once thought to be solid and stable for so long, can be turned upside down by a simple finding like this lol. It goes against everything I've learned and thought about so far...

Share this post


Link to post
Share on other sites
It's a memory leak imo. The application doesn't deconstruct properly. Beyond the obvious issues with stuff like memory, what about other handles the process has open? There's many things you can leak and different operating systems will behave differently when trying to clean up the process after exit. Some embedded systems might not clean it at all, older versions of Windows didn't either. Making it exit properly here is trivial and you're aware of the issue so there's no reason except laziness to not fix it imo.

Share this post


Link to post
Share on other sites
Quote:
Original post by owl
I don't see the problem if the program is going to exit anyway. To be a leak, the program should still be running.


Even if Windows does clean up your memory and handles for you, I can't imagine how leaving them around is good programming practice for C and C++. Plus it's not hard to imagine a class that causes trouble if it's destructor never gets called (especially when multiple threads and DLL's are involved).

Share this post


Link to post
Share on other sites
Ok, so not all hope is lost then - at least it's still a good programming practice not to leave memory leaks behind. :) Maybe I'm not that useless after all then. :D

Thanks.

Still, I can't believe I never realized that Windows XP does clean up after programs that do create memory leaks while running. Now that I think about it, it seems so obvious (I can think of many examples in the past that confirm this behaviour). This probably wasn't the case in Win 98, was it?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!