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

[Lubomir I. Ivanov]

On 10 April 2017 at 01:12, Thiago Macieira <thiago at macieira.org> wrote:
> 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.
>

i did a couple of tests to see if the singleton is even protected with
mingw 4.9.2:

gcc -v
gcc version 4.9.2 (i686-posix-dwarf-rev1, Built by MinGW-W64 project)

g++ test.cpp -Wall -std=c++11 -O1 -S -o test-meyer.S

so, it's guarded with ___cxa_guard_acquire() and it appears that the
c++11 flag doesn't matter much.
the "static Foo inst;" being outside of the function body is not guarded.

___cxa_guard_acquire() calls __gthr_win32_recursive_mutex_lock() which
has WaitForSingleObject().
so if the static initialization causes the deadlock the mingw
implementation might be the cause, indeed.

i see that recent qmutex.cpp has the object outside of the function.

lubomir
--