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

[Maarten Bosmans]

Here's a patch that includes the earlier patch and the separately send
hunk from this thread. Also add a (char *) cast to avoid a compiler
warning.

Please apply.

Maarten

2011/8/12 Maarten Bosmans <mkbosmans at gmail.com>:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Plug-some-memory-leaks-and-an-invalid-read.patch
Type: application/octet-stream
Size: 3790 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110812/70f0728d/attachment.obj>