I used Valgrind to check for memory leaks in several system programs, including ls, gedit and Make. I discovered that these programs do have memory leaks. Is this a serious problem whenever I use these programs? Why might the programmers who wrote these programs ignore the advice about preventing memory leaks?
-
I'm not sure, but I assume they know what they're doing. I mean, maybe for a specific program, leaking the memory isn't a big deal because it probably consumes a very small amount of memory. Or maybe part of they don't bother freeing all the memory as long as things go smooth. In other words, maybe sometimes it's not necessary for your program not to leak the memory that you should free all the memory it allocated depending on the fact that the OS takes care the memory as the program terminates. However, I still think it's what you should do.– kzidaneCommented Oct 13, 2014 at 19:33
Add a comment
|
1 Answer
Is this a serious problem whenever I use these programs? Why might the programmers who wrote these programs ignore the advice about preventing memory leaks?
Check out the top Google result for the search phrase "valgrind ls leaks". It's a bug report made to the GNU project's bug-coreutils mailing list back in 2011 that makes essentially the same claim (that the ls command leaks memory).
One of the programmers who maintains the GNU core utilities responds:
ls does leak but inconsequentially. Explicitly freeing the memory would only waste time managing the heap just before we'd exit anyway.
cheers, Pádraig.
In other words, since ls isn't a persistent application (i.e., one that remains open in a window, in a background process, or as a command line interface), the unfreed memory isn't a problem. As soon as it generates its output for you, ls exits and the operating system reclaims that memory. What's implied here is that the way the operating system recovers the unfreed memory is more efficient than the program could achieve on its own.
As for gedit, there is an open bug report from several years ago that only last month was marked as "Confirmed" on the GNOME bug tracker. It seems to only become an issue when opening very large files.
It's not necessarily that anyone is ignoring advice about preventing memory leaks. Real-world applications tend to have more source code than class projects and it can become very difficult to keep track of every memory allocation, especially when using libraries that themselves may have small leaks. If it doesn't negatively affect performance, then the programmer probably has better things to do than go back and perfect every little detail about something that works fine as-is.
