[pulseaudio-discuss] Valgrind complains about bluetooth on pulseaudio exit

[Tanu Kaskinen]

On Sun, 2014-11-23 at 21:15 +0500, Alexander E. Patrakov wrote:
> Hi.
> 
> Today I tried to valgrind pulseaudio, for reasons unrelated to 
> bluetooth. Result: found nothing about my bug, but got this on exit:
> 
> ==16639== Invalid read of size 8
> ==16639==    at 0x5D5F3F0: pa_hashmap_iterate (hashmap.c:245)
> ==16639==    by 0x1E71A5C9: adapter_free (bluez5-util.c:521)
> ==16639==    by 0x5D5F2DC: pa_hashmap_remove_all (hashmap.c:232)
> ==16639==    by 0x5D5F341: pa_hashmap_free (hashmap.c:120)
> ==16639==    by 0x1E71CAC5: pa_bluetooth_discovery_unref 
> (bluez5-util.c:1667)
> ==16639==    by 0x1E51243E: module_bluez5_discover_LTX_pa__done 
> (module-bluez5-discover.c:159)
> ==16639==    by 0x4E60B48: pa_module_free (module.c:227)
> ==16639==    by 0x4E61929: pa_module_unload_all (module.c:292)
> ==16639==    by 0x406476: main (main.c:1161)
> ==16639==  Address 0x1c57fe20 is 32 bytes inside a block of size 1,072 
> free'd
> ==16639==    at 0x4C2A20C: free (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==16639==    by 0x510395E: pa_xfree (xmalloc.c:131)
> ==16639==    by 0x1E71CAB4: pa_bluetooth_discovery_unref 
> (bluez5-util.c:1664)
> ==16639==    by 0x1E51243E: module_bluez5_discover_LTX_pa__done 
> (module-bluez5-discover.c:159)
> ==16639==    by 0x4E60B48: pa_module_free (module.c:227)
> ==16639==    by 0x4E61929: pa_module_unload_all (module.c:292)
> ==16639==    by 0x406476: main (main.c:1161)
> 
> There were no Bluetooth sinks and sources. Also, this PC does not have 
> ofono installed.

I tried to reproduce, but my bluetooth setup is currently totally broken
(bluetoothd isn't running), so there are no adapters to free, and the
bug appears to be related to adapter freeing.

I triggered another valgrind error when unloading
module-bluetooth-discover, though:

==8272== Invalid read of size 1
==8272==    at 0xFF88674: defer_cb (module.c:314)
==8272==    by 0x10235C63: dispatch_defer (mainloop.c:682)
==8272==    by 0x10236833: pa_mainloop_dispatch (mainloop.c:891)
==8272==    by 0x10236A00: pa_mainloop_iterate (mainloop.c:931)
==8272==    by 0x10236A59: pa_mainloop_run (mainloop.c:946)
==8272==    by 0x423F94: main (main.c:1136)
==8272==  Address 0x10a3b9b8 is 72 bytes inside a block of size 88 free'd
==8272==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8272==    by 0x102528C4: pa_xfree (xmalloc.c:131)
==8272==    by 0xFF8811E: pa_module_free (module.c:240)
==8272==    by 0xFF88382: pa_module_unload_by_index (module.c:267)
==8272==    by 0xE8DDED7: module_bluetooth_discover_LTX_pa__done (module-bluetooth-discover.c:84)
==8272==    by 0xFF8806C: pa_module_free (module.c:227)
==8272==    by 0xFF88256: pa_module_unload (module.c:253)
==8272==    by 0xFF88698: defer_cb (module.c:315)
==8272==    by 0x10235C63: dispatch_defer (mainloop.c:682)
==8272==    by 0x10236833: pa_mainloop_dispatch (mainloop.c:891)
==8272==    by 0x10236A00: pa_mainloop_iterate (mainloop.c:931)
==8272==    by 0x10236A59: pa_mainloop_run (mainloop.c:946)

I found the bug in module.c, but fixing it properly will take some time.
I hope I can get it fixed next week. It might fix the error you're
seeing too, but probably not.

-- 
Tanu