Probable memory leak in gnome-settings-daemon/gnome-volume-control-applet

I'm now at about about 3½ days of uptime and a little under 200 MiB of RSS (a little under 300 MiB virtual) for each of the processes mentioned in the report. I haven't noticed this kind of behaviour earlier but I usually don't have particularly long uptimes. Since this looks pretty similar to the original report, I'm confirming the bug.

I'm now logging the memory sizes for some time to see if it correlates with my use of the system somehow. At least it doesn't seem to grow constantly.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

After roughly 24 hours of valgrind:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27336 al 20 0 627m 483m 6448 R 18 24.8 248:05.19 memcheck-x86-li
27261 al 20 0 605m 471m 6000 R 13 24.2 188:32.78 memcheck-x86-li

Logs attached.

I'm seeing the same behaviour - both the gnome-settings-daemon and gnome-volume-control-applet are up at 100Mb after 1 days usage. I only noticed because my system slowed to a crawl and killing these processes resolved the issue.

Seems like a fairly major memory leak to have this kind of impact - hopefully this report will get some attention amongst the developers :)

After compiling a debug version of gnome-volume-control-applet and running in valgrind, I have identified the cause of the leak in that program. But I am not sure if it is related to the gsd bug.

Basically what is happening is that every time an application creates a pulseaudio sink, gvca adds it into a hash table. But when the application frees the audio sink, gvca does not remove it from the hash table. Normally this would not leak anything like 300mb in a day, but another unrelated bug in either pulseaudio or wine is causing wine applications to open and close the audio sink several times per second. This causes the hash table to grow at a very high rate. I suspect gsd is using a similar amount of memory because it is mirroring the gvc settings.

@w1zard: Are you using wine? If so which version? And are you using spotify?

This video demonstrates the behaviour that turns a tiny insignificant leak into a huge problem:

http://www.youtube.com/watch?v=Xx5p6H8M2CI

Could people experiencing this bug please try to obtain a valgrind log with the following packages installed:

gnome-settings-daemon-dbgsym gnome-media-dbgsym libglib2.0-0-dbg libgtk2.0-0-dbg libpulse0-dbg

@Alistair Buxton, I've seen the leak as well (both volume applet and settings daemon). Right now both of them are using 13% each of my 8GB RAM (+8GB for swap) with an uptime of 10 days. I use Spotify using wine all day.

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
marcus 3553 0.4 13.8 1500724 1137968 ? Ssl Dec12 63:49 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
marcus 3768 0.2 13.5 1457092 1112064 ? S Dec12 43:12 gnome-volume-control-applet

Forgot a few things.
I'm using wine from winehq (1.1.32~winehq0~ubuntu~9.04-0ubuntu1). Also, isn't Spotify polling the volume because when lowering the volume during commercial the playback is paused - could that be the cause for the "flickering" in the gvca window?

These logs were done with --show-reachable=yes because Valgrind does not always see the memory as lost. The results are quite conclusive:

From gvca:
==12744== 122,531,944 bytes in 373,573 blocks are still reachable in loss record 6,971 of 6,971
==12744== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12744== by 0x45972E3: g_malloc (gmem.c:131)
==12744== by 0x45AD418: g_slice_alloc (gslice.c:824)
==12744== by 0x45AD714: g_slice_alloc0 (gslice.c:833)
==12744== by 0x44FD8F6: g_type_create_instance (gtype.c:1654)
==12744== by 0x44E2747: g_object_constructor (gobject.c:1383)
==12744== by 0x44E3707: g_object_newv (gobject.c:1171)
==12744== by 0x44E4589: g_object_new_valist (gobject.c:1323)
==12744== by 0x44E470D: g_object_new (gobject.c:1086)
==12744== by 0x80515FE: gvc_channel_map_new_from_pa_channel_map (gvc-channel-map.c:287)
==12744== by 0x8057552: _pa_context_get_sink_input_info_cb (gvc-mixer-control.c:886)
==12744== by 0x452DB6C: context_get_sink_input_info_callback (introspect.c:1028)
==12744== by 0x4C6CEA4: run_action (pdispatch.c:274)
==12744== by 0x4C6D475: pa_pdispatch_run (pdispatch.c:326)
==12744== by 0x4525148: pstream_packet_callback (context.c:357)
==12744== by 0x4C726E7: do_something (pstream.c:816)
==12744== by 0x4C5D11D: callback (iochannel.c:119)
==12744== by 0x4511F32: ??? (in /usr/lib/libpulse-mainloop-glib.so.0.0.4)
==12744== by 0x458EE87: g_main_context_dispatch (gmain.c:1960)
==12744== by 0x459272F: g_main_context_iterate (gmain.c:2591)
==12744== by 0x4592B9E: g_main_loop_run (gmain.c:2799)
==12744== by 0x418D418: gtk_main (gtkmain.c:1218)
==12744== by 0x804EEF0: main (applet-main.c:92)
==12744==
==12744== LEAK SUMMARY:
==12744== definitely lost: 14,792 bytes in 23 blocks
==12744== indirectly lost: 19,683 bytes in 540 blocks
==12744== possibly lost: 46,340 bytes in 1,836 blocks
==12744== still reachable: 157,160,155 bytes in 1,524,594 blocks
==12744== suppressed: 11,664 bytes in 266 blocks

And in gsd:

==12804== 122,420,096 bytes in 373,232 blocks are possibly lost in loss record 5,433 of 5,433
==12804== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12804== by 0x48702E3: g_malloc (gmem.c:131)
==12804== by 0x4886418: g_slice_alloc (gslice.c:824)
==12804== by 0x4886714: g_slice_alloc0 (gslice.c:833)
==12804== by 0x481C8F6: g_type_create_instance (gtype.c:1654)
==12804== by 0x4801747: g_object_constructor (gobject.c:1383)
==12804== by 0x4802707: g_object_newv (gobject.c:1171)
==12804== by 0x4803589: g_object_new_valist (gobject.c:1323)
==12804== by 0x480370D: g_object_new (gobject.c:1086)
==12804== by 0x651BA2E: gvc_channel_map_new_from_pa_channel_map (gvc-channel-map.c:287)
==12804== by 0x6521382: _pa_context_get_sink_input_info_cb (gvc-mixer-control.c:886)
==12804== by 0x5CF2B6C: context_get_sink_input_info_callback (introspect.c:1028)
==12804== by 0x5D41EA4: run_action (pdispatch.c:274)
==12804== by 0x5D42475: pa_pdispatch_run (pdispatch.c:326)
==12804== by 0x5CEA148: pstream_packet_callback (context.c:357)
==12804== by 0x5D476E7: do_something (pstream.c:816)
==12804== by 0x5D...

Bug is present in git.gnome.org master, so I have submitted to Gnome bugzilla.

Thank you for sending the bug to GNOME

This is now fixed at gnome.
Don't know why and it has not been updated automatically for some reason.
"Bug watch updates for GNOME Bug Tracker are disabled. "

This bug was fixed in the package gnome-media - 2.29.91-0ubuntu1

---------------
gnome-media (2.29.91-0ubuntu1) lucid; urgency=low

  * New upstream version:
    - gnome-volume-control
    + bug 599663 - make changing the volume unmute (lp: #460390)
    + bug 606325 - show unamplified volume on outputs as well
    + bug 606914 - applet should not set volume on startup (lp: #498550)
    + bug 598921 - handle the last input source being removed
    + bug 605694 - fix GvcChannelMap leak (lp: #485923)
    + bug 607681 - set default scroll-wheel delta to 5% (lp: #358131)
    + other misc fixes
    - gstreamer-profiles:
    + bug 524364 - libglade -> gtkbuilder (lp: #508227)
    - general
    + bug 609933 - fix linking with pedantic linkers
    + bug 101811 - remove unnecessary markup from glade message
    - added/updated translations
  * debian/control.in:
    - build-depends on libgladeui-1-dev and not on libglade2-dev
  * debian/gnome-media-common.install,
    debian/libgnome-media0.install:
    - new version update
 -- Sebastien Bacher <email address hidden> Tue, 23 Feb 2010 11:48:04 +0100

Are we going to see this fix backported to Karmic? I've built a version of the gnome-media package with the patch from upstream for now, but I'd prefer to have an official fix.

not likely, karmic is not a lts and focus now is on lucid, users didn't have real issues with that in months it can probably wait until lucid now and the workaround is easy enough, just restart the applet if needed

Fair enough. I've put my package for Karmic in my ppa (https://launchpad.net/~apb-curlybrackets/+archive/ppa) in the hope that it'll help anyone else with this problem. It hit me quite hard as I leave Spotify running under Wine most of the time and I ended up having to reboot every 4-5 days (as that was easier than restarting both the applet and gnome-settings-daemon).

Installed the packages from abayliss's karmic PPA, logged out and logged back in and used spotify. The good news is the gnome-volume-control-applet has not grown from 12MB over night. The bad news is the gnome-settings-daemon has grown from 10MB to 161MB overnight.

 gnome-settings-daemon stills leaks in latest lucid. 200MB in one day, Spotify and winamp running.

I just checked and gsd has a copy-pasted version of the exact same source file that caused the problem in gvca.

Compare:
gnome-volume-control/src/gvc-mixer-stream.c
vs
gnome-settings-daemon/plugins/media-keys/cut-n-paste/gvc-mixer-stream.c

They are the same file so I have opened a new upstream bug for gsd.

Well, I can't figure out how to add two remote watches to this bug, and gnome remote watches are disabled anyway. So here is the GSD bug:

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

This bug was fixed in the package gnome-settings-daemon - 2.29.92-0ubuntu1

---------------
gnome-settings-daemon (2.29.92-0ubuntu1) lucid; urgency=low

  * debian/patches/91_update_gvc_source.patch:
    - update gvc copy using the current gnome-media version to fix a leak issue
      (lp: #485923)

  [ Didier Roche ]
  * debian/control.in:
    - bump libgnome-desktop-dev build-dep
  * debian/patches/90_autoreconf.patch:
    - refreshed
 -- Sebastien Bacher <email address hidden> Tue, 09 Mar 2010 10:18:09 +0100

I've also uploaded a version of gsd to my ppa with the same fix applied. Usual caveats apply (should have said that before :) ), all I did was apply the patch and rebuild, it seems to work OK for me, YMMV.