Why free memory on application quit?

Member
Posts: 45
Joined: 2006.07
Post: #31
My understanding is that historically, it used to be very important to release all resources you requested from the OS in certain operating systems, especially Windows 3.1 thru 98. If an OS has finite resources and doesn't reclaim them from an application once it's terminated, it's definitely, as OSC suggests, an OS bug. Nevertheless, this is exactly what happened with those versions of windows.

That's one of the many reasons many users found the need to reboot them daily, as I understand it.

It should be far less important now. The only reason I can imagine you'd want to deallocate everything on exit is to (a) cover for OS bugs, or (b) check for memory leaks. But if the leak checking tools don't complain, then it should be just fine.
Quote this message in a reply
Member
Posts: 131
Joined: 2004.10
Post: #32
At work we try to clean up on shutdown. We have coded in leak tracking into our program and all the leaks get dumped out at the end of a run. The main reason is to find leaks and plug them. When we develop we hardly stress the program like some of our clients so the small leaks that we may miss or sometimes ignore could quickly add up for a client. Plus this can point to code that is less than stellar (I.E. new coders on a big project) or design flaws, memory allocated but would never be freed due to an exception case.

Even on the product I work with that allocates GBs of RAM, the freeing up will not be noticed by the user. It's a practice I've found to be very useful partly for the above reasons. YMMV.
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.01
Post: #33
mattz Wrote:It should be far less important now. The only reason I can imagine you'd want to deallocate everything on exit is to (a) cover for OS bugs, or (b) check for memory leaks. But if the leak checking tools don't complain, then it should be just fine.
I think a lot of people have the wrong idea about what a memory leak really is.

Here's a very basic example:

Code:
char* buffer = malloc(32); // ask for a 32 byte buffer
memset(buffer, 0, sizeof(buffer)); // fill it with zeros to sanitize it
buffer = NULL;

The variable 'buffer' in and of itself is a pointer. It points to a memory address that's exclusive to this program. That area in memory has been allocated (32 bytes in size) and cleared out. So we have 32 continuous bytes in memory ready to be used. The next line says 'buffer' is now NULL. That line of code does nothing to the actual 32-byte block of memory. All it does is forgets where that pointer points to. That's a memory leak. Memory that has been allocated, flagged as in-use, but not able to be used.

Memory leaks such as this are really bad for applications such as a server, that have to remain up and running for a very long time. Regardless of how much RAM you have installed in your computer, a progam has a finite amount of RAM it can use. So eventually it could hit an "out of memory" barrier if it allocates, and discards objects frequently (this is very true in game dev) without clean up. It's been said over and over again, when your app exits, the OS reclaims the memory. The only time I've seen an OS not reclaim the memory is when it saves it into cache so that the next time you run the app it starts up faster.

One thing I haven't seen discussed yet is WHERE memory is allocated. See below:
Code:
char* buffer = malloc(32);
char buffer2[32];

There's a very important difference between those 2 lines of code. They both end up giving you a 32 byte buffer to fill with data. But WHERE that 32 byte buffer comes from is significant. The first line that uses malloc is allocating memory on the heap. The second line creates an array of 32 bytes on the stack. What's the difference? Memory allocated on the stack is cleared out by the time the function returns. Memory allocated on the heap remains for the lifespan of the application.

The variable "buffer" is a pointer. Suppose you define it locally in a function. By the time the function ends and returns, "buffer" no longer exists. This is called scope. But "buffer" was a pointer to a 32 byte chunk of memory we allocated on the heap, but now "buffer" doesn't exist so we don't have the address to that 32 byte of memory.... that is what a memory leak is.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  My game crashes on quit... hangt5 17 8,301 Jan 30, 2005 09:38 PM
Last Post: hangt5
  Carbon Apple quit Event troubles deekpyro 3 5,779 May 7, 2002 06:24 AM
Last Post: deekpyro