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 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? > > 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
