Re: [pulseaudio-discuss] PULSE_MEMPOOL_DISABLE=1 is incompatible with srbchannel
On 2014-12-05 00:42, Peter Meerwald wrote: Hello David, 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 :-) did you test srbchannel on record streams? I get one max-block-size worth of crap before capturing actual audio data; can you reproduce? Found it: this is due to block_id collision between the rwpool and the standard mempool, so when the first block in the record stream comes in, pa_memimport_get finds the srbchannel memblock instead and returns it. Will figure out a fix shortly. -- 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
Re: [pulseaudio-discuss] PULSE_MEMPOOL_DISABLE=1 is incompatible with srbchannel
Hi, Cool, thanks for testing and keep 'em coming :-) did you test srbchannel on record streams? I get one max-block-size worth of crap before capturing actual audio data; can you reproduce? Found it: this is due to block_id collision between the rwpool and the standard mempool, so when the first block in the record stream comes in, pa_memimport_get finds the srbchannel memblock instead and returns it. that was quick :) and your description matches my debugging observation Will figure out a fix shortly. cool! thanks, p. -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] PULSE_MEMPOOL_DISABLE=1 is incompatible with srbchannel
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:
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 0x0855ce77 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x0855e27a in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x05d67fbb in pa_memblock_acquire (b=optimized out) at
pulsecore/memblock.c:486
b = 0x0
#3 0x05d74b1c 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 0x18bb016d in setup_srbchannel (c=0x1c6f5a10) at
pulsecore/protocol-native.c:2615
srb = optimized out
mc = {memblock = 0x3e803f7, 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.
--
Alexander E. Patrakov
From a160d6e1513aea0efb71ad798d409f0a16399430 Mon Sep 17 00:00:00 2001
From: Alexander E. Patrakov patra...@gmail.com
Date: Thu, 4 Dec 2014 22:43:59 +0500
Subject: [PATCH] srbchannel: Don't fail assertion with PULSE_MEMPOOL_DISABLE
---
src/pulsecore/srbchannel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pulsecore/srbchannel.c b/src/pulsecore/srbchannel.c
index a0f916e..925d740 100644
--- a/src/pulsecore/srbchannel.c
+++ b/src/pulsecore/srbchannel.c
@@ -230,7 +230,7 @@ pa_srbchannel* pa_srbchannel_new(pa_mainloop_api *m, pa_mempool *p) {
pa_srbchannel* sr = pa_xmalloc0(sizeof(pa_srbchannel));
sr-mainloop = m;
-sr-memblock = pa_memblock_new_pool(p, -1);
+sr-memblock = pa_memblock_new(p, -1);
srh = pa_memblock_acquire(sr-memblock);
pa_zero(*srh);
--
2.1.3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PULSE_MEMPOOL_DISABLE=1 is incompatible with srbchannel
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 0x0855ce77 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x0855e27a in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x05d67fbb in pa_memblock_acquire (b=optimized out) at
pulsecore/memblock.c:486
b = 0x0
#3 0x05d74b1c 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 0x18bb016d in setup_srbchannel (c=0x1c6f5a10) at
pulsecore/protocol-native.c:2615
srb = optimized out
mc = {memblock = 0x3e803f7, 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
