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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to