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
