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>
