Bug#665732: reopen: vlc: GUI latency/unresponsiveness to clicks on control options

[Johann Klammer]

Rémi Denis-Courmont wrote:
> tags 665732 = moreinfo help unreproducible
> thanks
>
> 	Hello,
>
> Le mardi 26 février 2013 17:33:21, Johann Klammer a écrit :
>> Adding a usleep(10000) after the last aout_unlock() in aout_DecPlay() in
>> src/audio_output/dec.c solves the problem for me.
>
> Unfortunately that does not really help pinpoint the problem. It is likely a
> race, but it could be anywhere. Without a stack trace of the freeze or a way
> to reproduce the problem, there is nothing I, as a VLC developer, can do about
> this bug report.
>
Could only find those two points where the audio output lock was taken...

> Changing volume (with ALSA) exhibits a noticeable delay of a few tenth of a
> second, due to buffering in the ALSA driver. That is neither new and nor
> fixable. Several seconds of delay is abnormal.
>

it's more than just seconds(perhaps because it's single core box)...
Lockup can be broken by doing stuff to shake up the scheduling...
switching console<->xorg, disk activity etc..

>
> While a kernel bug cannot be completely ruled out, a bug in libpthread seems
> more probable. With that in mind, it would be good to know if the bug
> reproduces with *unoptimized* libpthread builds (on i386, this can be achieved
> by removing the libc6-i686 package).
>

I am using the i386 versions of everything...

Starting the gdb while it's locked up shows that
it blocks in ___lll_lock_wait in eglibc's lowlevellock.S...
the i486 variant...(there's no i386 because of xchg insn)
...also it's the same for i686(which just includes the 486 version)...
And there's a __GI_poll done somewhere inside libasound.
...it sleeps there...

Yes, the sched_yield() does the trick, too.