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)? > > 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? With the latest patches committed there are only two valgrind-related issues left on my radar. The one above and the write_volume one from another thread. I did try two load all modules in pulseaudio under valgrind, but some did not succeed, most notably bluetooth and echo-cancel related stuff. If someone could try those under valgrind, that would be great. I'm available on irc for support in getting it running, if necessary. Also, all testing was done just loading the daemon. pactl list did work, but playing audio was not possible, probably because my machine is far too slow to run realtime audio with valgrind's checks enabled. If someone with a more beefier computer could just load the default configuration under valgrind and play some audio to test for memory leaks in those code paths, that would be great too. Maarten
