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 605694 - gnome-volume-control-applet never frees/finalizes PA channel maps.
gnome-volume-control-applet never frees/finalizes PA channel maps.
Status: RESOLVED FIXED
Product: gnome-media
Classification: Deprecated
Component: gnome-volume-control
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: gnome media maintainers
gnome media maintainers
Depends on:
Blocks:
 
 
Reported: 2009-12-29 19:52 UTC by Alistair Buxton
Modified: 2010-02-02 10:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix GvcChannelMap leak (1.00 KB, patch)
2010-02-02 10:40 UTC, Bastien Nocera
committed Details | Review

Description Alistair Buxton 2009-12-29 19:52:35 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
Comment 1 Alistair Buxton 2009-12-29 19:57:59 UTC
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
Comment 2 Bastien Nocera 2010-02-02 10:40:27 UTC
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.
Comment 3 Bastien Nocera 2010-02-02 10:40:43 UTC
Attachment 152824 [details] pushed as 53ab42f - Fix GvcChannelMap leak