[pulseaudio-discuss] PA 7.0 crash with KDE

[David Henningsson]

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