Tinderbox owners: deadlock, beware

[Norbert Thiebaud]

On Fri, Aug 14, 2015 at 6:45 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
> In the window of time between
>
>> commit 54f10a9654b617c4c993044e52e7bd40d0151c53
>> Author: Stephan Bergmann <sbergman at redhat.com>
>> Date:   Thu Aug 13 12:04:55 2015 +0200
>>
>>     tdf#93404: Forgot to launch WakeUpThread
>>
>>     ...in 017f250764ec7b4ecb82ac19f5b3f68cadf1bf56 "Ensure WakeUpThread is
>> joined
>>     before exit"
>>
>>     Change-Id: Iaa5a5772f099b11229bd40c3cc10d863ef0ad5b3
>
>
> and
>
>> commit ded58e062c9e9b8b5f9dc9a18777a1be68359a91
>> Author: Stephan Bergmann <sbergman at redhat.com>
>> Date:   Thu Aug 13 15:16:38 2015 +0200
>>
>>      Related tdf#93404: Fix deadlock when joining WakeUpThread
>>
>>      ...after 54f10a9654b617c4c993044e52e7bd40d0151c53 "tdf#93404: Forgot
>> to launch
>>      WakeUpThread," when the WakeUpThread blocks on locking
>>      StatusIndicatorFactory::m_mutex in StatusIndicatorFactory::update()
>> while the
>>      joining thread blocks on
>> StatusIndicatorFactory::impl_stopWakeUpThread() ->
>>      WakeUpThread::stop() -> Thread::join().
>>
>>      Change-Id: I3480014b1f522901064ea9b71ffa2ebf5d74fef5
>
>
> master builds could easily deadlock in certain unit tests.  (And similarly
> for libreoffice-5-0.)

I wonder if we should go to the trouble of trying to remove that range
from the bibisect repo ?
iow how likely is the deadlock on 'normal' qa-test uses ?

Norbert