views:

622

answers:

8

Is there any point to freeing memory in an atexit() function?

I have a global variable that gets malloc'ed after startup. I could write an atexit() function to free it, but isn't the system going to reclaim all that memory when the program exits anyway?

Is there any benefit to being tidy and actively cleaning it up myself?

+7  A: 

In all modern operating systems, you can safely assume that all memory will be freed when the program exits.

JesperE
+1 for pointing out that this is a feature of the operating system, not the language.
unwind
+8  A: 

One benefit on freeing it is that if you ever do any memory leak testing that tries to match allocations with deallocations over the lifetime of the process you won't get false positives from this kind of deliberate leak.

Rob Walker
Talking about memory leak testing: http://valgrind.org.
JesperE
Purify used to do memory leak testing before calling the atexit() cleanups. It was annoying. But that was also a decade ago - it could have changed since then.
Jonathan Leffler
+11  A: 

Not in C - it's like rearranging the deck chairs while the ship sinks around you.

In C++ the answer is different, because objects can delete temporary files and so forth in their destructors, so you need to make sure those get called.

Sherm Pendley
+2  A: 

On Windows, some calls return memory that belongs to the OS or to COM and you need to free that memory explicitly or it will not be freed even after your process terminates. But this is a rare scenario.

Ferruccio
+2  A: 

You should free() if your code that's calling atexit() is part of dynamically-loaded shared library (with dlopen(), for example). In this case the atexit handler will be called at dlclose() time so the heap will continue to exist for the rest of the process to use.

Adam Mitz
+7  A: 

Seeing as malloc()/free() normally involve extensive data structures that exist in userspace, free()ing memory when your program ends can actually be a performance drain. If parts of the data structure are paged to disk, they need to be loaded from disk only to be discarded!

Whereas if you terminate without free()ing, the data paged out to disk can die in peace.

Of course free()ing at other times is usually beneficial as further malloc()s can re-use the space you freed and free() might even unmap some memory which can then be used by other processes.

Artelius
+1  A: 

not freeing memory before process termination isn't a memory leak. it's a memory leak when you lose a handle to it. but memory is not the only type of resource, and other resources persist across processes (like window handles and file handles), so you do need to 'free' those.

Dustin Getz
+1  A: 

Actually being tidy can be interesting when your program evolves.It forces you to write cleanup function when you create "initialisation" funtions. The benefit comes when your program becomes more complex, and you want to restart part of the program. If you have already written working cleanup functions, it is less likely that you suddenly forgot some cleanup when "restarting" part of your program.

Writing cleanup functions "lazily" ie only when you need it is more error-prone. Writing cleanup functions forces you to think about cleanup and eventual cleanup dependency. It permit easier code reuse of a part of your code in another project.

So yes freeing in an atexit is useless, and so is closing file descriptor. However writing and maintaining cleanup fucntion as your code grows can be a constraint that will force you to think about what you are doing

shodanex