On Thu, 2014-01-30 at 08:16 +0530, Arun Raghavan wrote:
> On Wed, 2014-01-29 at 21:23 +0200, Tanu Kaskinen wrote:
> > I tried valgrind today myself (which I do way too seldomly), and I found
> > one memory leak in module-card-restore, which gets triggered when
> > changing card profiles. I pushed a fix for that to master. There's still
> > one memory leak in alsa-lib, which I expect to be triggered once per
> > loaded instance of module-alsa-card, so it's not very serious. I didn't
> > bother tracking down the bug in alsa-lib.
>
> If you have the it handy, can you dump the trace somewhere on bugzilla
> so we don't lose track?
==8634== HEAP SUMMARY:
==8634== in use at exit: 52,492 bytes in 461 blocks
==8634== total heap usage: 39,922 allocs, 39,461 frees, 5,539,674 bytes allocated
==8634==
==8634== 80 bytes in 5 blocks are definitely lost in loss record 55 of 92
==8634== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8634== by 0x37596463BD: ??? (in /usr/lib64/libasound.so.2.0.0)
==8634== by 0x3759646549: ??? (in /usr/lib64/libasound.so.2.0.0)
==8634== by 0x375963C11C: snd_hctl_load (in /usr/lib64/libasound.so.2.0.0)
==8634== by 0x37596470D8: snd_mixer_load (in /usr/lib64/libasound.so.2.0.0)
==8634== by 0xD60B306: prepare_mixer (alsa-util.c:1506)
==8634== by 0xD60B474: pa_alsa_open_mixer (alsa-util.c:1529)
==8634== by 0xDC5968A: init_jacks (module-alsa-card.c:503)
==8634== by 0xDC5A588: module_alsa_card_LTX_pa__init (module-alsa-card.c:754)
==8634== by 0x1017998A: pa_module_load (module.c:174)
==8634== by 0xE691E33: verify_access (module-udev-detect.c:341)
==8634== by 0xE692393: card_changed (module-udev-detect.c:430)
==8634==
==8634== LEAK SUMMARY:
==8634== definitely lost: 80 bytes in 5 blocks
==8634== indirectly lost: 0 bytes in 0 blocks
==8634== possibly lost: 0 bytes in 0 blocks
==8634== still reachable: 52,412 bytes in 456 blocks
==8634== suppressed: 0 bytes in 0 blocks
This may be a PulseAudio bug too, I'm not sure. The reason why I think
it's an alsa-lib bug is this comment in prepare_mixer():
/* Note: The hctl handle returned should not be freed.
It is closed/freed by alsa-lib on snd_mixer_close/free */
if (hctl && (err = snd_mixer_get_hctl(mixer, dev, hctl)) < 0) {
pa_log_info("Unable to get hctl of mixer %s: %s", dev, pa_alsa_strerror(err));
return -1;
}
As far as I can tell, we close all mixer handles when we don't need them
anymore, so based on that comment, all hctl resources should get
released too. But maybe the comment is wrong or I don't understand it
correctly. I don't know the relationships between snd_mixer_open(),
snd_mixer_load(), snd_mixer_close() and snd_mixer_free(). We call both
snd_mixer_open() and snd_mixer_load(), but we never call
snd_mixer_free().
--
Tanu
