GNOME Bugzilla – Bug 704627
Memory leak when loading playlist
Last modified: 2018-05-24 17:56:06 UTC
I tried to load a playlist with 1,852 songs from a file. Rhythmbox crashed. I researched further and discovered that it was blowing through huge amounts of memory. I have a 6GB memory limit set on my login session. When I removed that memory limit and tried again, Rhythmbox was able to import the playlist, but when it was done, it was using *** almost 17GB of RAM ***. When I then exited and restarted rhythmbox, it was only using 1.7GB, so whatever it's doing to burn through all that RAM while loading the playlist doesn't appear to be necessary. I think there must be a memory leak of some sort.
Please see "Debugging" section on https://projects.gnome.org/rhythmbox/developers.html and report back. Plus without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
I've spent several hours using valgrind to isolate the memory leak. I have not been successful. A stack trace is not going to be useful to you. As I said in comment #0, the problem is that rhythmbox is blowing through so much memory that it is exceeding the memory limit set in /etc/security/limits.conf for processes running in login sessions. That means that it's getting a Trace/BPT signal from the kernel when the kernel decides to kill it because of the memory limit violation. That signal could be received in any arbitrary location on the code, and it will have no relation to where the memory leak is. You can reproduce this easily simply by following the steps I've already laid out: load a large playlist, observe how much RAM rhythmbox is using, then exit and restart rhythmbox and observe that it is using much less RAM, thus proving that the act of loading a new playlist at runtime for some reason consumes much more RAM than loading a new playlist on startup. You can also prove that this RAM isn't freed: load a large playlist, observe the RAM usage of the process, delete the playlist, observe the RAM usage of the process, and then load the same playlist again. If memory were being managed properly, the RAM usage would not grow after the second time you load the playlist, but in fact it grows pretty much as much as it did the first time.
It doesn't matter how big is the play list. I've just reached the same result with a play list of 12 songs - that means the memory leak. (If) The operation succeeds in the end, there's nothing displayed - the play list content is not added. Running "strace rhythmbox" and then trying to import the play list seems to go through the whole user home directory looking for the files. Is it possible that rhythmbox doesn't close file descriptors?
here's the strace http://uloz.to/xbuhZsJt/rhythmbox-bz704627-strace-gz
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/1295.