After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704627 - Memory leak when loading playlist
Memory leak when loading playlist
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Importing
2.99.x
Other Linux
: High critical
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-21 01:22 UTC by Jonathan Kamens
Modified: 2018-05-24 17:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan Kamens 2013-07-21 01:22:01 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.
Comment 1 André Klapper 2013-07-26 08:09:00 UTC
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!
Comment 2 Jonathan Kamens 2013-07-26 15:10:54 UTC
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.
Comment 3 goddard 2016-02-08 12:26:57 UTC
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?
Comment 4 goddard 2016-02-08 13:15:38 UTC
here's the strace http://uloz.to/xbuhZsJt/rhythmbox-bz704627-strace-gz
Comment 5 GNOME Infrastructure Team 2018-05-24 17:56:06 UTC
-- 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.