On 2015-10-16 14:59, Takashi Iwai wrote:
On Fri, 16 Oct 2015 13:50:58 +0200,
David Henningsson wrote:
On 2015-10-16 10:35, Takashi Iwai wrote:
On Fri, 16 Oct 2015 09:16:04 +0200,
David Henningsson wrote:
(Adding pulseaudio-discuss to CC)
On 2015-10-15 16:26, Takashi Iwai wrote:
Hi David,
we got bug reports with PA 7.0 where the recent KDE crashes.
It seems that srbchannel=no works around it, so there is still
something fishy there.
The bug report is found at
http://bugzilla.opensuse.org/show_bug.cgi?id=950487
Hi Takashi and thanks for reporting.
I've tried running PA 7.0's pactl under valgrind, and it reports no
errors here. Still, looking at the one of the backtraces the value of f
is something interesting:
#6 flush (f=f@entry=0x4545454545454545) at pulsecore/fdsem.c:143
#7 0x00007fe30f378fc2 in pa_fdsem_before_poll (f=0x4545454545454545) at
pulsecore/fdsem.c:295
#8 0x00007fe30f38f697 in srbchannel_rwloop (sr=0x25bdd40) at
pulsecore/srbchannel.c:203
Does 0x4545454545454545 mean anything specific on OpenSUSE? (Like, a
magic clear value or something?)
I don't think it's openSUSE specific. It's likely the guard put by
either gcc or glibc.
FWIW, we pass the default optimization flags like:
CFLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall \
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables \
-fasynchronous-unwind-tables -g -fPIE
The problem was reported from both gcc-4.8 and gcc-5.x systems, so the
gcc version is likely irrelevant.
Also, are there any distro patches to OpenSUSE and if so, where can I
find them?
No, there is no patches apparently relevant with this. Actually there are
three patches, one is to check an additional environment check in
start-pulseaudio-x11, another is to suppress an error log at
sockaddr_prepare(), and the last is a fix in memset() size in
echo-cancel/adrian-aec.c. But all these should be safe.
All sources, patches, build log and binaries are found in OBS, e.g. at
https://build.opensuse.org/package/show/multimedia:libs/pulseaudio
Ok, thanks.
I've been trying to analyze the backtrace.
My guess is that the srbchannel is being destroyed somehow, but I don't
see how. Any chance we can get more info from this, e g, build
pulseaudio's client library with -DDEBUG_SRBCHANNEL=1 and then get a log
like this:
PULSE_LOG=99 pactl info
...which includes the crash?
OK, I'm building a package with the debug enabled and will ask
reporters to test with it.
Also, if the srbchannel gets destroyed and replaced by another
srbchannel (eh?), it's possible that the below would help:
diff --git a/src/pulsecore/pstream.c b/src/pulsecore/pstream.c
index 8c14fbb..06063bb 100644
--- a/src/pulsecore/pstream.c
+++ b/src/pulsecore/pstream.c
@@ -223,7 +223,7 @@ static bool srb_callback(pa_srbchannel *srb, void
*userdata) {
pa_assert(p->srb == srb);
do_pstream_read_write(p);
- return p->srb != NULL;
+ return p->srb == srb;
}
...but that's an even wilder guess, at this point.
But such a condition should have been caught by pa_assert(), no?
It's about if p->srb gets destroyed during the call to
do_pstream_read_write, and replaced by another p->srb. But I'm not
seeing how that could happen, so it's probably not that...
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
