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?
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.
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.