GNOME Bugzilla – Bug 615342
[gstalsamixer] leaks
Last modified: 2011-11-07 20:13:46 UTC
Looks like we are leaking data in gstalsamixer. ==26529== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==26529== by 0x68D4D51: strdup (strdup.c:43) ==26529== by 0x80C9DD6: ??? (in /usr/lib/libasound.so.2.0.0) ==26529== by 0x80D1AC4: ??? (in /usr/lib/libasound.so.2.0.0) ==26529== by 0x80CE58A: snd_hctl_open (in /usr/lib/libasound.so.2.0.0) ==26529== by 0x80D83FC: snd_mixer_attach (in /usr/lib/libasound.so.2.0.0) ==26529== by 0x7A255E8: gst_alsa_mixer_new (gstalsamixer.c:62) ==26529== by 0x7A2666A: gst_alsa_mixer_element_change_state (gstalsamixerelement.c:210) ==26529== by 0x5514AFB: gst_element_change_state (gstelement.c:2531) ==26529== by 0x5517C7A: gst_element_set_state_func (gstelement.c:2487) ==26529== by 0x401481: test_alsa_mixer_track (alsa.c:83) ==26529== by 0x504846E: srunner_run_all (check_run.c:372) ==26529== by 0x504353A: gst_check_run_suite (gstcheck.c:556) ==26529== by 0x4013A1: main (alsa.c:134) This happens on various setups (f12, lucid, karmik). After googling a bit, it looks like we should call the counterpart of snd_mixer_attach : snd_mixer_detach(handle, mixer_name);
We're also leaking other things: F12: ==20240== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==20240== by 0x3E78037B11: ??? (in /lib64/libasound.so.2.0.0) ==20240== by 0x3E7803F734: ??? (in /lib64/libasound.so.2.0.0) ==20240== by 0x3E7803C25A: snd_hctl_open (in /lib64/libasound.so.2.0.0) ==20240== by 0x3E7804604C: snd_mixer_attach (in /lib64/libasound.so.2.0.0) ==20240== by 0xB961DA0: gst_alsa_mixer_new (gstalsamixer.c:62) ==20240== by 0xB962DFA: gst_alsa_mixer_element_change_state (gstalsamixerelement.c:210) ==20240== by 0x508226B: gst_element_change_state (gstelement.c:2531) ==20240== by 0x50857D7: gst_element_set_state_func (gstelement.c:2487) ==20240== by 0x401241: test_alsa_mixer_track (alsa.c:83) ==20240== by 0x4E24F2E: srunner_run_all (check_run.c:372) ==20240== by 0x4E200DA: gst_check_run_suite (gstcheck.c:556) ==20240== by 0x401892: main (alsa.c:134) karmik/lucid: ==11124== at 0x4C25153: malloc (vg_replace_malloc.c:195) ==11124== by 0x4013C20: _dl_close_worker (dl-close.c:374) ==11124== by 0x401454B: _dl_close (dl-close.c:742) ==11124== by 0x400E385: _dl_catch_error (dl-error.c:178) ==11124== by 0x6BAB2AB: _dlerror_run (dlerror.c:164) ==11124== by 0x6BAB00E: dlclose (dlclose.c:48) ==11124== by 0x809CF85: ??? (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x809D4FC: snd_config_searcha_hooks (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x809D65F: snd_config_searchva_hooks (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x809D7ED: ??? (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x809D9C5: snd_config_search_definition (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x80A93A4: ??? (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x80A60CA: snd_hctl_open (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x80AFEEC: snd_mixer_attach (in /usr/lib/libasound.so.2.0.0) ==11124== by 0x79FB568: gst_alsa_mixer_new (gstalsamixer.c:62) ==11124== by 0x79FC5EA: gst_alsa_mixer_element_change_state (gstalsamixerelement.c:210) ==11124== by 0x5513E9B: gst_element_change_state (gstelement.c:2531) ==11124== by 0x5517407: gst_element_set_state_func (gstelement.c:2487) ==11124== by 0x4013B1: test_alsa_mixer_track (alsa.c:83) ==11124== by 0x504559E: srunner_run_all (check_run.c:372) Googling some more showed that we should also maybe call snd_mixer_free() before calling snd_mixer_close() and snd_mixer_detach()
Created attachment 178838 [details] [review] alsa: fix "leaks" (aka cached configuration data)
Is snd_config_update_free_global() threadsafe? IMHO we should just add this to the supression files, cached data is no leak.
It seems to be, it calls snd_config_lock();
Comment on attachment 178838 [details] [review] alsa: fix "leaks" (aka cached configuration data) Ok, still I don't think we should clear the cached configuration data. It's cached for a reason and not really a leak ;) Lets better get the suppression files updated.
Created attachment 198341 [details] [review] valgrind: add ALSA leaks fixed by snd_config_update_free_global If they go when calling snd_config_update_free_global, they're not really bug leaks, but more like intentional ones we don't want to get told about.
Generating the suppressions caused a couple suspicious ones to be written out, but they seem to go when calling snd_config_update_free_global so in they go.
commit e13ff2521cb3df681d38d8091ea48fbaea6a9e02 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Oct 5 15:29:54 2011 +0100 valgrind: add ALSA leaks fixed by snd_config_update_free_global If they go when calling snd_config_update_free_global, they're not really bug leaks, but more like intentional ones we don't want to get told about. https://bugzilla.gnome.org/show_bug.cgi?id=615342
> Generating the suppressions caused a couple suspicious ones to be written out, > but they seem to go when calling snd_config_update_free_global so in they go. For what it's worth: these are really quite specific, it's usually a good idea to reduce them to the bare minimum using wildcards like "obj: blabla.*" or "..." (between lines).