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 at 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? 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. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
