On 2014-12-04 18:54, Alexander E. Patrakov wrote: > Hello. > > I am still trying to valgrind pulseaudio. The previous attempt yielded > nothing about the bug that I was trying to debug, but found a Bluetooth > issue. This time, I thought that maybe some memory pool or flist was > causing valgrind to mistakenly consider the samples to be properly > initialized. And found PULSE_MEMPOOL_DISABLE as a way to disable this > (potentially valgrind-unfriendly) pool. Thus: Cool, thanks for testing and keep 'em coming :-) I was unaware of PULSE_MEMPOOL_DISABLE, but it does not make sense to set up a shared ringbuffer in case the ringbuffer memory is not shared. (See just sent patch.) Looking at PULSE_MEMPOOL_DISABLE in general, it looks like a quick-and-dirty debug flag. E g, the shm file is still created even if PULSE_MEMPOOL_DISABLE is set, which does not make sense to me. In case we decide that PULSE_MEMPOOL_DISABLE should be handled better, maybe we could also improve the srbchannel error message (which with the patch becomes just "Failed to create srbchannel"), but for now I think my patch is okay. > > PULSE_MEMPOOL_DISABLE=1 valgrind --trace-children=yes --db-attach=yes > ./src/pulseaudio > > In the other terminal, I entered this: > > pactl load-module module-null-sink > > Result: > > E: [memcheck-amd64-] memblock.c: Assertion 'b' failed at > pulsecore/memblock.c:486, function pa_memblock_acquire(). Aborting. > > (gdb) bt full > #0 0x000000000855ce77 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1 0x000000000855e27a in abort () from /lib64/libc.so.6 > No symbol table info available. > #2 0x0000000005d67fbb in pa_memblock_acquire (b=<optimized out>) at > pulsecore/memblock.c:486 > b = 0x0 > #3 0x0000000005d74b1c in pa_srbchannel_new (m=0xa0c05e8, p=0xa0d1ec0) > at pulsecore/srbchannel.c:234 > capacity = <optimized out> > readfd = <optimized out> > srh = <optimized out> > sr = 0x1c6fb1d0 > __func__ = "pa_srbchannel_new" > #4 0x0000000018bb016d in setup_srbchannel (c=0x1c6f5a10) at > pulsecore/protocol-native.c:2615 > srb = <optimized out> > mc = {memblock = 0x3e8000003f7, index = 97918596, length = > 477068544} > fdlist = {1, 15} > srbt = {readfd = 477068032, writefd = 0, memblock = 0x5103647 > <pa_xmalloc+23>} > t = <optimized out> > > <snip the rest> > > I have tried to apply the attached "obvious" patch, but instead got this: > > ==23564== Syscall param socketcall.sendto(msg) points to uninitialised > byte(s) > ==23564== at 0x7C0F6BB: send (in /lib64/libpthread-2.20.so) > ==23564== by 0x5D57351: pa_write (core-util.c:445) > ==23564== by 0x5D61238: pa_iochannel_write (iochannel.c:226) > ==23564== by 0x5D72EA3: do_write (pstream.c:653) > ==23564== by 0x5D73BB4: do_pstream_read_write (pstream.c:201) > ==23564== by 0x50EF143: dispatch_pollfds (mainloop.c:657) > ==23564== by 0x50EF143: pa_mainloop_dispatch (mainloop.c:900) > ==23564== by 0x50EF519: pa_mainloop_iterate (mainloop.c:931) > ==23564== by 0x50EF5BF: pa_mainloop_run (mainloop.c:946) > ==23564== by 0x406DB5: main (main.c:1136) > ==23564== Address 0x1c6c898c is 108 bytes inside a block of size 65,536 > alloc'd > ==23564== at 0x4C28F40: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==23564== by 0x5103646: pa_xmalloc (xmalloc.c:65) > ==23564== by 0x5D68F8E: memblock_new_appended (memblock.c:238) > ==23564== by 0x5D68F8E: pa_memblock_new (memblock.c:221) > ==23564== by 0x5D74B0F: pa_srbchannel_new (srbchannel.c:233) > ==23564== by 0x18BB016C: setup_srbchannel (protocol-native.c:2615) > ==23564== by 0x18BB016C: command_auth (protocol-native.c:2783) > ==23564== by 0x5D6ED6C: pa_pdispatch_run (pdispatch.c:343) > ==23564== by 0x18BB2C7F: pstream_packet_callback > (protocol-native.c:4898) > ==23564== by 0x5D7165A: do_read (pstream.c:882) > ==23564== by 0x5D73C3C: do_pstream_read_write (pstream.c:195) > ==23564== by 0x50EF143: dispatch_pollfds (mainloop.c:657) > ==23564== by 0x50EF143: pa_mainloop_dispatch (mainloop.c:900) > ==23564== by 0x50EF519: pa_mainloop_iterate (mainloop.c:931) > ==23564== by 0x50EF5BF: pa_mainloop_run (mainloop.c:946) > > ...and "Connection failure: Protocol error" on the pactl side. > -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic