Haunting a Windows "Subsurface not start but becoming zombie" bug

[Thiago Macieira]

Em domingo, 9 de abril de 2017, às 04:09:43 PDT, Stefan Fuchs escreveu:
> Hi All,
> 
> I'm trying to haunt another issue I'm seeing already since a long time
> (months):
> 
> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
> mean I click on the icon and no window and also no crash info appears.
> After that I have a zombie Subsurface.exe running. I now for the first
> time reproduced this with the MXE debug build and again attached drmingw
> to the zombie exe.
> 
> Can s.o. guess s.th. from the output?

Looks like it's a deadlock, caused by the GCC implementation on Windows 
violating a C++11 requirement.

You have three (or more) threads running. The interesting ones are:
 A) an aux thread that is calling PeekMessage, but somehow recurses through a 
hook to __gthr_win32_recursive_mutex_lock
 B) an aux thread that is trying to lock a mutex and is stuck in 
QMutexPrivate::allocate, having called __gthr_win32_recursive_mutex_lock
 C) the main thread, that is stuck in a mutex wait

Guessing at what in QMutexPrivate::allocate could cause a call to 
__gthr_win32_recursive_mutex_lock, I can only come up with the function-local 
static:

FreeList *freelist()
{
    static FreeList list;
    return &list;
}

The C++11 standard says that such initialisation must be thread-safe and must 
not deadlock. Hence why I think that this is a violation of the C++ standard.

In any case, the code above no longer exists. It was changed in Qt 5.7.1. 
Please upgrade.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center