Freeing in an atexit()
Asked Answered
M

8

13

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?

Manda answered 23/10, 2008 at 19:24 Comment(1)
Sounds like a dupe, see #2214127.Skiing
J
22

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.

Jumbuck answered 23/10, 2008 at 19:27 Comment(0)
P
15

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.

Pornography answered 23/10, 2008 at 19:26 Comment(1)
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.Propellant
V
14

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.

Vermillion answered 28/10, 2008 at 5:29 Comment(0)
N
13

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

Neumeyer answered 23/10, 2008 at 19:25 Comment(0)
K
7

Actually being tidy can be interesting when your program evolves.It forces you to write cleanup function when you create "initialisation" functions. 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 function as your code grows can be a constraint that will force you to think about what you are doing

Kinson answered 3/6, 2010 at 15:43 Comment(0)
O
5

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.

Outshoot answered 24/10, 2008 at 0:16 Comment(0)
A
2

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.

Avenue answered 23/10, 2008 at 19:29 Comment(0)
E
1

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.

Ettieettinger answered 11/11, 2008 at 4:25 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.