Jump to content
  • Advertisement
Sign in to follow this  
autir

Memory leaks' time scope

This topic is 3644 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

Hello When a C/C++ program presents a memory leak, for how long is this memory "lost" to the system? After the program exits, is the operating system able to reclaim the lost memory? Or is a reboot required? If it depends upon the OS, we are talking about Linux with gcc/g++ and Windows XP with DevC++. Thank you

Share this post


Link to post
Share on other sites
Advertisement
Generally, the OS knows what memory the application is allocating, even if the app itself doesn't. In most cases, when memory is leaked, it's cleaned up by the OS when the program terminates.

Share this post


Link to post
Share on other sites
Your compiler shouldn't determine when memory leaks are cleared, as nsto119 said, the OS knows what memory the app is using and frees it when the program terminates.

Share this post


Link to post
Share on other sites
Usually, everything that is handled by the operating system as an acquire-release semantic is released when the program ends (if it hasn't already been released). This includes memory, open files, and so on). All major recent operating systems do this for you, although arguably some minor operating systems (such as those on embedded platforms, especially cell phones) might skip some of the cleanup.

Nobody will clean up after you if you use an implicit acquire-release semantic (such as creating a lock file or registry entry and manually removing that file or registry entry to unlock).

Share this post


Link to post
Share on other sites
Quote:
Original post by autir
When a C/C++ program presents a memory leak, for how long is this memory "lost" to the system? After the program exits, is the operating system able to reclaim the lost memory? Or is a reboot required?


Languages are about source code. Most of them do not deal with OS.

When compiled for target platform, the resulting code is ran as a process. To interact with IO, a run-time library of sorts is usually provided (it's possible to run code directly on CPU with no OS).

This run-time library provides mechanism to interact with various hardware resources. For practical reasons, OS provides this functionality through a certain API.

Since performance issues have lessened through time, most modern OSes can afford to implement this API in such a manner, that once a process terminates, all resources claimed by said process are safely released.

The whole process is not language or OS specific, it all depends on implementation of given API. For the particular case it's somewhat safe to assume that anything your process claims will be released once the process terminates.

While it's possible to avoid well behaved resource management and let OS deal with it, this approach isn't recommended, and definitely not to be taken as any kind of a rule.

Simply put: release what you claim (not just memory, files and other resources too) explicitly.
Once you know what you're doing really well, you may find it viable to skip certain parts for some very specific reasons.
But regardless of how you do it, not releasing resources which need to be released is almost without exception poor design or buggy coding.

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!