GNOME Bugzilla – Bug 605694
gnome-volume-control-applet never frees/finalizes PA channel maps.
Last modified: 2010-02-02 10:40:46 UTC
Every time an application creates a pulseaudio sink, gvca adds some information about 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 very much memory, 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. If I leave a wine app running over night, gvca will be using 200mb of ram in the morning. gnome-settings-daemon also ends up using a lot of ram, I think it is mirroring the mixer settings. This bug is present in both 2.28.1 (Ubuntu Karmic) and git master. The Launchpad bug is here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/485923 Summary of what I found using valgrind (full logs also attached.) These logs were done with --show-reachable=yes because Valgrind does not always see the memory as lost: 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
OK, so the full valgrind logs are too big for bugzilla. If you want them, they're on the Launchpad bug, or here: http://launchpadlibrarian.net/37125702/valgrind-logs.tar.gz
Created attachment 152824 [details] [review] Fix GvcChannelMap leak For each created GvcMixerStream, we created a new channel map. Make sure it's unref'ed when we're done with it.
Attachment 152824 [details] pushed as 53ab42f - Fix GvcChannelMap leak