Ubuntu
rhythmbox package

rhythmbox leaking memory

Bug #1031449 reported by Lev Kokotov
128
This bug affects 60 people
Affects Status Importance Assigned to Milestone
Rhythmbox
New
Undecided
Unassigned
ubuntu-nexus7
Invalid
Undecided
Unassigned
rhythmbox (Ubuntu)
Fix Released
High
Matt Fischer
Declined for Raring by Didier Roche-Tolomelli
Precise
Fix Released
Undecided
Matt Fischer
Quantal
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
Large memory leak in Rhythmbox that manifests itself primarily when changing tracks. The leak for changing through 50 tracks is around 17MB. More tracks = more leaks. This bug hits memory constrained platforms especially hard, but all users should be able to listen to music for an afternoon without running out of memory.

[Test Case]
I loaded 50 random MP3 tracks from my collection onto a clean system. Some had album art, some did not. Lengths varied from 1 min to 20 mins, most were 3-4 mins long. I started watching rhythmbox with smem, updating every 10 seconds. I then started ryhthmbox and began playing audio. I did two test cases then:

1) I let each track play for 1-2 seconds and then skipped to the next track. The original precise version 2.96-0ubuntu4.2 leaks heavily as the tracks cycle:

foo@localhost:~$ while true; do smem -H -P ^rhythmbox; sleep 10; done
  779 mfisch rhythmbox 0 25568 27387 37380
  779 mfisch rhythmbox 0 32632 34726 45428
  779 mfisch rhythmbox 0 33564 35664 46372
  779 mfisch rhythmbox 0 35132 37194 47864
  779 mfisch rhythmbox 0 36664 38726 49396
  779 mfisch rhythmbox 0 38180 40272 50972
  779 mfisch rhythmbox 0 40020 42108 52804
  779 mfisch rhythmbox 0 41204 43304 54012
  779 mfisch rhythmbox 0 41220 43300 53988
  779 mfisch rhythmbox 0 41244 43343 54052
  779 mfisch rhythmbox 0 42340 44444 55160
  779 mfisch rhythmbox 0 50288 52391 63120

2) Another way was just to load the tracks and let them play. I watched this one for over 90 minutes. It still leaks, just more slowly, especially when it gets into some of the longer tracks.

mfisch@localhost:~$ while true; do smem -P ^rhythmbox; sleep 120; done
  765 mfisch rhythmbox 0 32136 35148 46948
  765 mfisch rhythmbox 0 33800 35997 46956
  765 mfisch rhythmbox 0 33800 35999 46960
  765 mfisch rhythmbox 0 34248 36456 47464
  765 mfisch rhythmbox 0 34240 36450 47460
  765 mfisch rhythmbox 0 34244 36452 47460
  765 mfisch rhythmbox 0 34248 36456 47464
  765 mfisch rhythmbox 0 34308 36520 47532
  765 mfisch rhythmbox 0 34308 36520 47532
  765 mfisch rhythmbox 0 34312 36524 47536
  765 mfisch rhythmbox 0 34312 36524 47536
  765 mfisch rhythmbox 0 34904 37118 48132
  765 mfisch rhythmbox 0 34904 37118 48132
  765 mfisch rhythmbox 0 35032 37244 48256
  765 mfisch rhythmbox 0 35032 37244 48256
  765 mfisch rhythmbox 0 35408 37620 48632
  765 mfisch rhythmbox 0 35408 37620 48632
  765 mfisch rhythmbox 0 35800 38018 49036
  765 mfisch rhythmbox 0 35800 38018 49036
  765 mfisch rhythmbox 0 36172 38388 49404
  765 mfisch rhythmbox 0 36172 38388 49404
  765 mfisch rhythmbox 0 36412 38630 49648
  765 mfisch rhythmbox 0 36412 38630 49648
  765 mfisch rhythmbox 0 36720 38936 49952
  765 mfisch rhythmbox 0 36720 38936 49952
  765 mfisch rhythmbox 0 37020 39238 50256
  765 mfisch rhythmbox 0 37020 39238 50256
  765 mfisch rhythmbox 0 37384 39600 50616
  765 mfisch rhythmbox 0 37384 39600 50616
  765 mfisch rhythmbox 0 37688 39904 50920
  765 mfisch rhythmbox 0 37688 39904 50920
  765 mfisch rhythmbox 0 37988 40204 51220
  765 mfisch rhythmbox 0 37988 40204 51220
  765 mfisch rhythmbox 0 38296 40512 51528
  765 mfisch rhythmbox 0 38296 40512 51528
  765 mfisch rhythmbox 0 38300 40516 51532
  765 mfisch rhythmbox 0 38300 40516 51532
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 38688 40906 51924
  765 mfisch rhythmbox 0 39096 41312 52328

[Regression Potential]
The potential here is that Rhythmbox will not work correctly and may crash. Freeing memory that is actually needed later will result in a segfault. If this happened users would experience crashes when playing music. However, I feel this risk is mitigated via testing and the fact that this code has been used upstream for over a year now. I did check the gir library because I was concerned that a breakage may affect other pieces, but it appears that only rhythmbox itself and plugins uses it.

[Explanation of Fix]
I cherry picked commits from June of 2012 from Rhythmbox's git tree to build the patch. These commits are already in use in Q and R. The commits I pulled are from the 2 upstream gnome bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=677738
https://bugzilla.gnome.org/show_bug.cgi?id=678208

After examining these commits, I found that 7ea940f doesn't apply, the file it patches doesn't exist in this version. Also commit 5b281f5 was
superceded by 7cdf4cd. This leaves the following commits in the patch: 0c5a47c 7cdf4cd fc1e8ca 3dec1ff ad8ab01 96aa2cd 5b281f5 195c2a7 8999cca

I then built a copy of rhythmbox and installed it. Here are the results from running Test 1 from above with the patch applied, as you can see the mem leak is corrected:

ufa@localhost:~$ while true; do smem -H -P ^rhythmbox; sleep 10; done
  806 ufa rhythmbox 0 25188 27072 36836
  806 ufa rhythmbox 0 33168 35348 45840
  806 ufa rhythmbox 0 33460 35634 46120
  806 ufa rhythmbox 0 33836 36022 46520
  806 ufa rhythmbox 0 33940 36094 46560
  806 ufa rhythmbox 0 34156 36306 46768
  806 ufa rhythmbox 0 34440 36608 47088
  806 ufa rhythmbox 0 34140 36324 46820
  806 ufa rhythmbox 0 33844 35992 46452
  806 ufa rhythmbox 0 33896 36065 46548
  806 ufa rhythmbox 0 36000 38189 48696
  806 ufa rhythmbox 0 34724 36880 47364

(original description)
Memory usage : 10.9% and constantly increasing (that's over 400 MB on my system with 4 GB)

Playing a playlist of MP3 files.

This can't be normal, right?

-Lev

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: rhythmbox 2.96-0ubuntu4.1
ProcVersionSignature: Ubuntu 3.2.0-27.43-generic 3.2.21
Uname: Linux 3.2.0-27-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu11
Architecture: amd64
Date: Tue Jul 31 14:07:07 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
 LANGUAGE=en_CA:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: rhythmbox
UpgradeStatus: No upgrade log present (probably fresh install)

See original description
Revision history for this message
Lev Kokotov (lev-kokotov) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rhythmbox (Ubuntu):
status: New → Confirmed
Sambo (ud-sambo)
description: updated
Revision history for this message
Nicolas Delvaux (malizor) wrote :
Download full text (4.2 KiB)

I ran rhythmbox with valgrind (~30 minutes playing various file types, using the sound indicator and keyboard shortcuts to play/stop/switch between songs, with the shuffle mode)

==10276== LEAK SUMMARY:
==10276== definitely lost: 5,021,263 bytes in 329 blocks
==10276== indirectly lost: 8,623,848 bytes in 2,381 blocks
==10276== possibly lost: 31,876,828 bytes in 16,677 blocks
==10276== still reachable: 33,412,186 bytes in 278,143 blocks
==10276== suppressed: 0 bytes in 0 blocks
==10276== Reachable blocks (those to which a pointer was found) are not shown.
==10276== To see them, rerun with: --leak-check=full --show-reachable=yes
==10276==
==10276== ERROR SUMMARY: 15930 errors from 8359 contexts (suppressed: 31 from 3)

2 biggest leaks:

==10276== 8,215,364 (840 direct, 8,214,524 indirect) bytes in 35 blocks are definitely lost in loss record 67,187 of 67,188
==10276== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10276== by 0x5BF6AE0: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==10276== by 0x4E79BE0: load_external_art_cb (rb-shell.c:516)
==10276== by 0xD841A13: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0)
==10276== by 0xD841434: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0)
==10276== by 0x596A50A: g_cclosure_marshal_generic (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==10276== by 0x5969C1A: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==10276== by 0x597AD70: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==10276== by 0x5982D7D: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==10276== by 0x5983241: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==10276== by 0x4EB5741: do_load_request (rb-ext-db.c:625)
==10276== by 0x5475E7B: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.3)
==10276== by 0x546515D: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.3)
==10276== by 0x5C13247: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==10276== by 0x5C129E4: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==10276== by 0x5EA5E99: start_thread (pthread_create.c:308)
==10276== by 0x61AECBC: clone (clone.S:112)
==10276==
==10276== 17,916,336 bytes in 15 blocks are possibly lost in loss record 67,188 of 67,188
==10276== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10276== by 0x9BA8F64: gdk_pixbuf_new (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==10276== by 0x3A5A9D25: ??? (in /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so)
==10276== by 0x9BAED14: ??? (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==10276== by 0x9BAFC2A: gdk_pixbuf_loader_write (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==10276== by 0x4E79BA6: load_external_art_cb (rb-shell.c:500)
==10276== by 0xD841A13: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0)
==10276== by 0xD841434: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0)
==10276== by 0x596A50A...

Read more...

Revision history for this message
Nicolas Delvaux (malizor) wrote :

I may add that Rhythmbox leaks as much on Quantal (I did not check with valgrind though).
That's why I also linked the ubuntu-nexus7 project, as suggested here: http://www.chizang.net/alex/blog/2012/11/23/memory-leaks-in-ubuntu-episode-i-detection/

Revision history for this message
Nicolas Delvaux (malizor) wrote :

Here is the full valgrind log.
Happy hacking!

Jani Monoses (jani)
Changed in rhythmbox (Ubuntu Quantal):
status: Confirmed → Won't Fix
status: Won't Fix → Confirmed
Changed in ubuntu-nexus7:
status: New → Invalid
Revision history for this message
William Hua (attente) wrote :

I rememchecked (raring) this without any success at duplicating the problems from the originally attached valgrind log. I'm attaching my valgrind output (which was generated after applying the changes at https://bugzilla.gnome.org/show_bug.cgi?id=694293). Memory usage is still pretty high however, on the order of tens of MBs.

Revision history for this message
Benjamin Bach (benjaoming) wrote :

Dear package maintainers -- please be our heroes and fix this :)

Memory leaks were fixed in Rhythmbox 2.97 and 2.98 as noted in #976534. I'm currently running RB 2.97 from ubuntuupdates.org and it works without leaks.

This was my result before:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28905 username 20 0 1978m 1.4g 15m S 39 35.4 33:44.59 rhythmbox

This is my result using the webupd8team PPA:

10545 username 20 0 550m 103m 20m S 4 2.6 52:17.58 rhythmbox

As you can see, even after running for almost twice as long, it uses only 2.6% memory, and before it was sipping some 35%.

The following upstream report mentions a lot of commits with memory leak fixes -- perhaps they could be targeted for backporting.

https://bugzilla.gnome.org/show_bug.cgi?id=677738

Revision history for this message
Matt Fischer (mfisch) wrote :

I'm working on backporting to Precise now, the results are promising. I'll see if we can get a SRU approved.

Matt Fischer (mfisch)
Changed in rhythmbox (Ubuntu Quantal):
status: Confirmed → Fix Released
Revision history for this message
Matt Fischer (mfisch) wrote :

I'll have a debdiff tomorrow for raring.

description: updated
Changed in rhythmbox (Ubuntu):
assignee: nobody → Matthew Fischer (mfisch)
Revision history for this message
Matt Fischer (mfisch) wrote :

I have a PPA here if anyone wants to try it. Debdiff still coming.

https://launchpad.net/~mfisch/+archive/testing

Revision history for this message
Matt Fischer (mfisch) wrote :
Changed in rhythmbox (Ubuntu):
importance: Undecided → High
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

I think mfisch meant precise

Changed in rhythmbox (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Matt Fischer (mfisch) wrote :

Thanks Didier, I did mean precise.

Changed in rhythmbox (Ubuntu Precise):
assignee: nobody → Matthew Fischer (mfisch)
status: New → Triaged
Matt Fischer (mfisch)
Changed in rhythmbox (Ubuntu Precise):
status: Triaged → In Progress
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Lev, or anyone else affected,

Accepted rhythmbox into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/rhythmbox/2.96-0ubuntu4.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in rhythmbox (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
franglais.125 (franglais.125-deactivatedaccount) wrote :

I tested the fix. Although I don't claim it fixes all possible memory leaks, the memory usage is substantially improved.
Using a given set of tracks the leakage went from ~90MB to only 5MB or so (and it didn't increase past this value).
However, if cover-art is activated, the memory usage can be worse, as it seems to load every image and keep it in memory. (This is minor though).

tags: added: verification-done
removed: verification-needed
Revision history for this message
Simon Déziel (sdeziel) wrote :

Thanks for this update, rythmbox's memory stays constant when changing songs. I've been testing for the last 8 hours and things look good.

Revision history for this message
Colin Watson (cjwatson) wrote : Update Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rhythmbox - 2.96-0ubuntu4.3

---------------
rhythmbox (2.96-0ubuntu4.3) precise; urgency=low

  * debian/patches/git_leak_fixes.patch:
    - backport upstream commits to fix memory leaks (LP: #1031449)
 -- Matthew Fischer <email address hidden> Mon, 10 Jun 2013 20:24:24 -0600

Changed in rhythmbox (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.