Rhythmbox uses excessive memory/Possible Leak?

[Darryl Clarke]

Dapper Current,
$ apt-cache policy rhythmbox
rhythmbox:
  Installed: 0.9.2cvs20060124-0ubuntu1

I have a very large library:

(right after starting rhythmbox, and library update is completed:)
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25235 dclarke 15 0 333m 91m 15m S 0 9.1 0:36.98 rhythmbox

After pressing 'play', there are now two PIDs:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25235 dclarke 15 0 345m 92m 16m S 4 9.2 0:41.15 rhythmbox
25299 dclarke 15 0 337m 77m 1348 S 0 7.7 0:00.00 rhythmbox

After 3 songs have played:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25235 dclarke 15 0 355m 93m 16m S 5 9.3 0:57.35 rhythmbox
25431 dclarke 15 0 346m 77m 1252 S 0 7.8 0:00.00 rhythmbox

The original PIDs memory has jumped.

I understand this is mostly shared memory, however, after being open (not necessarily playing) for a day the value of "VIRT" for the original PID will be up over 750MB.

As far as features go:
I have no podcasts configured.
[ ] Watch my library for new files
[x] Share My Music
[x] Enable Audio Scrobbler

[Darryl Clarke (dclarke)]

After roughly 5 hours of playtime:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25235 dclarke 15 0 1028m 102m 16m S 4 10.2 12:21.56 rhythmbox
  304 dclarke 15 0 1019m 86m 1252 S 0 8.6 0:00.00 rhythmbox

I am putting this as 'critical' due to the fact that after such playtime my kernel has begun killing processes due to low memory.

[Phil Bull (philbull)]

Thanks for the report.

Does this only happen with rhythmbox, or can it occur with other music players?

You might like to try to profile the memory usage of rhythmbox. Install the 'valgrind' package and run the following command from the terminal (all one line):

valgrind --tool=massif --depth=5 --alloc-fn=g_malloc
--alloc-fn=g_realloc --alloc-fn=g_try_malloc --alloc-fn=g_malloc0
--alloc-fn=g_mem_chunk_alloc rhythmbox

Rhythmbox will be very slow, but let it run for a little while. When you close rhythmbox, you should get a couple of files written to your current directory (called massif something). Open the ps file for a nice graph of memory allocation by the process over time. This *might* shed some light on the problem, I don't know.

Also, I've reduced the severity until this can be confirmed.

Thanks again

[Darryl Clarke (dclarke)]

I ran the command you specified for approximately 3 hours and now I have a handful (46 each) of massif.*.ps and massif.*.txt files, I also have the output generated by the command itself.

Shall I attach them all to this report as a .tgz or attach them each individually?

Until specified otherwise, the output is all here:
http://sn0rkb0x.flatlinesystems.net/~dclarke/bugs/30185/

I will check out and see if this occurs with other media players. Normally none of the others that I use (bmp or totem-video) get the chance to playback for a long period of time.

[Phil Bull (philbull)]

Thanks for your diligence! The output should be just fine where it is. Hopefully someone with more knowledge of this sort of thing will be able to make something of them, or else suggest a more appropriate test you can run.

I'm wondering about the features you said you were using (Audioscrobbler, music sharing) - what happens if you disconnect from the Internet and then use rhythmbox for a while? Or disable these features? (No need to run the profiler again).

[Darryl Clarke (dclarke)]

After trying other media players I've discovered that it's not directly Rhythmbox.

Just for more info, I am loading an m3u that contains all files found in my library that Rhythmbox uses. It's over 28,000 songs.

beep-media-player shows none of this behaviour over about 3 hours. It's memory usage stays pretty close to where it starts.

totem-gstreamer started at
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7658 dclarke 15 0 288m 41m 15m S 4 4.2 6:54.95 totem
... after a few hours of playback ...
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7658 dclarke 15 0 529m 42m 15m S 3 4.2 8:23.67 totem
 9030 dclarke 15 0 505m 28m 1284 S 0 2.8 0:00.00 totem

I've also noticed that in both cases, the VIRT column increases by 8MB (sometimes 10MB) each song wheter it's played through or skipped. Skipping backwards yeilds the same increase.

I'm not sure which direction this should go, but it's definitely at a lower level than the applications themselves.

gstreamer0.10 bug?

[Phil Bull (philbull)]

Give a smaller playlist a try, only about 2000 songs, if possible, and run that for a few hours. It might be a playlist handling bug somewhere.

With beep-media-player, are you using the gstreamer or xine backend? Could you try the xine backend with totem and try to reproduce the problem?

Thanks again

[Darryl Clarke (dclarke)]

AFAIK bmp doesn't use either of those backends.

My output options/plugs are only ALSA, OSS, and ESD. Mine is set to ALSA to match the rest of my system.

I have put a 2000 song playlist in totem-gstreamer right now, I'll switch to totem-xine after and will get back to you with the results soon.

[Darryl Clarke (dclarke)]

As promised...

totem-gstreamer
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 1749 dclarke 15 0 275m 27m 15m S 4 2.7 0:08.86 totem
 1759 dclarke 15 0 234m 10m 1372 S 0 1.0 0:00.00 totem
after 1 hour... totem-gstreamer
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 1749 dclarke 15 0 495m 31m 15m S 5 3.2 2:17.25 totem
 5856 dclarke 15 0 479m 17m 1284 S 0 1.8 0:00.00 totem

totem-xine
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 6087 dclarke 15 0 269m 16m 1100 S 0 1.6 0:00.00 totem
 6065 dclarke 15 0 237m 33m 17m S 2 3.3 0:05.44 totem
after 2 hours... totem-xine
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 6575 dclarke 15 0 268m 17m 1244 S 0 1.7 0:00.00 totem
 6065 dclarke 15 0 237m 33m 17m S 2 3.4 4:00.23 totem

totem-xine does not display the same memory increase as gstreamer based players, so again, I'll state that this bug is not at application level, but something the applications use.

[James "Doc" Livingston (jrl)]

The massif logs indicate the the heap size is ~55Mb, which is probably normal for a library that large.

The increasing VM size is an issue I noticed the other day, and reported as gnome bug 329713 (against gstreamer).

[Darryl Clarke (dclarke)]

Moving this to a more appropriate package to match an upstream report - and it has come clear that it is not a rhythmbox bug.

[Phil Bull (philbull)]

Some news from upstream:

http://bugzilla.gnome.org/show_bug.cgi?id=329713

Reported as fixed in CVS.

[Darryl Clarke (dclarke)]

As stated upstream, this fix has made its way in by way of

gstreamer0.10-plugins-base:
  Installed: 0.10.3-0ubuntu1