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?

  • 17
    Memory leaks are always undesirable. They represent resources that the entire system cannot utilize, including the host program, until the program terminates. – recursion.ninja Oct 13 '13 at 17:52
  • There are sufficient tools/libraries that deal with tracing memory leaks. It is worth the effort, as the API usage on your side might be wrong. – Joop Eggen Oct 13 '13 at 18:28
  • 1
    As a side note - valgrind's great but may report some false positives (I've seen them in GObject). – Maciej Piechotka Oct 13 '13 at 20:50
  • Computation depends on processing and on memory: the former being the code, and the latter the space it runs in. If you can't be trusted not to trash your own room, how can you possibly be expected to use it for something useful? – imallett Apr 30 '14 at 4:27
  • 1
    "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." – Jesse C. Slicer Oct 2 '15 at 20:51

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.

  • 2
    I have never worked in a company that restarted their server weekly... even less daily. I agree the cost to fix the leak might be to high to fix it but having this mindset is not good IMO – Rémi Dec 8 '17 at 14:38
  • @Rémi Most, if not all, MMO game servers do, usually on a weekly basis. – Sjoerd Dec 8 '17 at 23:35

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.

  • 4
    I mostly agree. I however suggest you stress out the importance of a memory leak. Memory leaks are not to take lightly and can cause some interesting "features" of your application. – Vladimir Kocjancic Oct 13 '13 at 20:26
  • @VladimirKocjancic: +1 for "feature" – Emilio Garavaglia Oct 14 '13 at 7:13
  • 1
    I just want to point out that a computer is capable of performing that one-in-a-million processing several million times quite quickly. Don't ever forget that. So if you take that into account then I agree with this answer, because it really does depend on the program. For an embedded system intended to run without human intervention, memory leaks are deadly. For a "grep" implementation you probably couldn't care less. – Dunk Oct 14 '13 at 17:40
  • 2
    @Dunk: It depends: if you grep through a very large file and your program leaks a few bytes for each input line, you could run out of memory. – Giorgio Oct 2 '15 at 21:40

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.

  • 1
    I wonder if leaks have anything to do with "boat coding"? – user251748 Dec 8 '17 at 17:35

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.