How important it is to fix memory leaks?

Question

I found by Valgring that some GTK+ programs leaks memory. How important it is to fix those leaks? I mean, often those programs works very well but on the other hand, one can never be sure if one wants to copy part of the leaking code to some other program. And I'm not sure if the idea of GTK+-programs is to work fast and therefore there are leaks.

So if I sometimes find a memory leak in an open source program, should I fix it or are there for example efficiency issues and therefore programmers original idea was to write some small leaking code?

Answer 1

How important it is to fix memory leaks depends on the severity of the problem and what else you have to do that is important. My experience is that small memory leaks tend to be rather benign for most applications. The lifetime of a desktop app session is not usually long enough to see any degradation from a small memory leak.

If you are writing a server that runs 24/7, then small memory leaks can add up over time and become a major problem. But that's why many companies schedule their servers to restart daily or weekly. The effort to find memory leaks is often excessive relative to what might be gained, so it's easier to restart the servers on a regular basis and move on to more important things.

Answer 2

For short running programs memory leaks are not as important; the OS will reclaim everything on termination, but they may cause other resources to not be released.

However short running is relative, a leak can spiral out of control in a few hours or stack up for weeks unnoticed.

My advice is to file a bug in the tracker with a proposed fix, if the lead cares he will fix it.

The type of leak is also important. It's possible that the allocation that leaks is a one-off allocation where the dev deliberately relied on the OS for the cleanup. These will give a false positive on valgrind.

Answer 3

In my admittedly dogmatic opinion on this one subject, there are no excuses for physical leaks at least in any library that aims to be widely applicable. So I'd seek to bug the GTK+ developers until they fix it themselves.

It is trivial enough for a library to register atexit callbacks to free any memory it allocates at least upon being unloaded. If it wants to avoid the expense of a boatload of teeny allocations, it shouldn't be doing them in the first place.

Even the laziest program that just wants to allocate a boatload of teeny chunks of memory at once could use a straightforward sequential allocator which just purges all memory at shutdown. If the allocator doesn't even want to deal with alignment, it can just pad every single chunk it pools to maximum alignment boundaries. If it was able to benefit with faster shutdown times by not freeing all those teeny chunks of memory individually, it likewise stands to benefit a great deal symmetrically in exchange for trivial effort by using such a sequential allocator which pools memory in a straight sequential fashion with much faster allocations than malloc and more cache-friendly memory patterns, only to have all the big blocks of contiguous memory pooled by the allocator freed when when the library is done. All the library has to do then is replace their malloc calls for which they don't bother to free with something like seq_malloc, and call seq_purge in an atexit callback to free all memory allocated upon being unloaded.

Otherwise you got this nasty library cluttering up messages in your memory leak detection tools you now have to filter out. Worse, if you don't systematically filter them out, they could obscure the leaks in your own application and your colleagues might develop the habit of overlooking them, reducing the usefulness of the leak detection tools in the first place in preventing your own team from pushing leaky code. It's gross and ugly and most of all I don't find the arguments in favor of doing this deliberately to be compelling at all given how trivial it is to use the solution above.

Logical leaks (the more complex kind that even garbage collection can't protect against) are a more complex issue, and there I could find some justification for short-lived programs to have logical leaks so long as they purge all that memory they allocated on shutdown since it requires a great deal of thought about resource management to avoid logical leaks (arguably more so in languages that have GC). But I don't find any reasonable excuse to avoid physical leaks given how trivial they are to avoid even in the laziest contexts.

Anyway, at the very least I'd filter out the leaks in valgrind so that they at least don't mess with your team's ability to spot your own.

Answer 4

FWIW, if a user reported a leak in an application that I work on, I would be very inclined to fix it (especially if they included code for the fix in the bug report!). That said, it might not happen immediately if the leak was small and other issues were more pressing (say, a crashing bug that happened frequently). But I would definitely appreciate it and work to fix it eventually. You should definitely let them know. They will either appreciate it and work to fix it (most likely), or they will not care and all it will have cost you is some time.