[pulseaudio-discuss] [PATCH] Plug some memory leaks and an invalid read

[Maarten Bosmans]

2011/8/12 Tanu Kaskinen <tanu.kaskinen at digia.com>:
> On Fri, 2011-08-12 at 01:24 +0300, Maarten Bosmans wrote:
>> There's still another invalid read reported by valgrind. The location
>> is the same as it was for the protocol-dbus.c error of the patch: the
>> hasmap_entry->key points to already freed memory.
>>
>>  Invalid read of size 1
>>     at 0x41070CE: pa_idxset_string_hash_func (idxset.c:69)
>>     by 0x4106064: remove_entry (hashmap.c:94)
>>     by 0x41061FD: pa_hashmap_free (hashmap.c:111)
>>     by 0x69C4626: pa_dbusiface_card_free (iface-card.c:548)
>>     by 0x69D1CEA: free_card_cb (iface-core.c:2054)
>>     by 0x4106215: pa_hashmap_free (hashmap.c:114)
>>     by 0x69D2105: pa_dbusiface_core_free (iface-core.c:2103)
>>     by 0x69E7169: module_dbus_protocol_LTX_pa__done (module-dbus-protocol.c:595)
>>     by 0x406DC51: pa_module_free (module.c:162)
>>     by 0x406E01D: pa_module_unload_all (module.c:210)
>>     by 0x4068842: core_free (core.c:169)
>>     by 0x406FD5D: pa_object_unref (object.c:64)
>>   Address 0x581edd8 is 0 bytes inside a block of size 21 free'd
>>     at 0x4025BF0: free (vg_replace_malloc.c:366)
>>     by 0x40F128C: pa_xfree (xmalloc.c:131)
>>     by 0x4063F4B: pa_card_profile_free (card.c:59)
>>     by 0x40649D7: pa_card_free (card.c:202)
>>     by 0x5051C75: module_alsa_card_LTX_pa__done (module-alsa-card.c:466)
>>     by 0x406DC51: pa_module_free (module.c:162)
>>     by 0x406E01D: pa_module_unload_all (module.c:210)
>>     by 0x4068842: core_free (core.c:169)
>>     by 0x406FD5D: pa_object_unref (object.c:64)
>>     by 0x805224D: pa_core_unref (core.h:184)
>>     by 0x805560B: main (main.c:1159)
>>
>> This one is more difficult to solve though, because the card.profile
>> is used in the hashmaps of two modules (alsa-card and dbus-protocol)
>> Any suggestions?
>
> Was this solved by your latest fix (in dbus_entry_free)?

No, sorry I wasn't clear. The dbus_entry_free was the last memory leak
that valgrind reported, but I didn't mention it to the ML earlier. I
probably should try running pulse with other than the default modules
loaded though, because I imagine some modules (e.g. rtp) could have
some leaks too.

The reading from freed memory error shown above is still a problem.

> Anyway, nice work! I've never really tried to run pulseaudio (or
> anything else, except paplay once) under valgrind, but I've heard about
> people trying and failing - could you share some instructions on how to
> get these valgrind reports on pulseaudio? Maybe even write something to
> the wiki?

Nothing special, really. Just:
valgrind --leak-check=yes /usr/local/bin/pulseaudio

I did find however, that using the valgrind on non-installed
pulseaudio did not work (either src/pulseaudio script or
src/.libs/pulseaudio), so every fix required a make && sudo make
install, which adds (on my slow machine) quite some time to see
whether the bugfix worked.

There are a lot of alsa-related warning that look to me that they are
not pulse's fault, so I added them to a suppressions file for
valgrind. I could share that file on the wiki, but may be it's better
for other folks trying valgrind out to determine for themselves what
to do with those warnings.

There are several other tools from valgrind other than the leak
detector. I ran helgrind and it came up with a lot of possible races
between threads. Analysing that output is for another day I guess.

Maarten