[pulseaudio-discuss] PULSE_MEMPOOL_DISABLE=1 is incompatible with srbchannel

[David Henningsson]

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