Clang produced qmake.exe and moc.exe crash

[rubenvb]

Bugzilla Link	10152
Resolution	FIXED
Resolved on	Oct 16, 2013 23:51
Version	trunk
OS	Windows NT
Depends On	#9965
CC	@AaronBallman,@asl,@isanbard

Extended Description

I built clang with GCC 4.6 for x86_64-w64-mingw32 (64-bit Windows) in Cmake's "Release" mode, modified InitHeaderSearch.cpp to point at all the headers, (applied some patches that were required to Clang and mingw-w64's float.h, see my email on cfe-dev) and modified Qt's qmake/makefile.win32-g++ to use clang++ instead of g++, changed the optimization to "-O0 -ggdb3" and removed the "-s" from the link line. I used the plain win32-g++ mkspec.

The resulting qmake binary runs OK seemingly (it starts processing Qt's pro files, and only crashes on exit), but segfaults for sure when invoked with "qmake --version" with this short backtrace:

#​0 0x00000000005fd015 in QBasicAtomicInt::deref (this=0x0)
#​1 0x0000000000000000 in ?? ()

This, of course, does not happen with plain GCC compiled qmake.

The crash on exit does not seem to affect qmake's runtime operation. The generated makefiles are fine and can be used to attempt building Qt (however, that's another story, euh bug report)

[rubenvb]

moc.exe is also miscompiled/linked it seems. When it's first run:

M:\Development\x64\Qt\bin\moc.exe -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -D_USE_MATH_DEFINES -DQLIBRARYINFO_EPOCROOT -DHB_EXPORT=Q_CORE_EXPORT -DQT_DLL -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"....\include" -I"....\include\QtCore" -I"tmp\rcc\release_shared" -I"tmp" -I"global" -I"m:\Development\Source\Qt\tools\shared" -I"m:\Development\Source\Qt\src\3rdparty\zlib" -I"m:\Development\Source\Qt\src\3rdparty\harfbuzz\src" -I"m:\Development\Source\Qt\src\3rdparty\md5" -I"m:\Development\Source\Qt\src\3rdparty\md4" -I"....\include\ActiveQt" -I"tmp\moc\release_shared" -I"m:\Development\Source\Qt\src\corelib" -I"." -I"m:\Development\Source\Qt\mkspecs\win32-g++" -D__GNUC__ -DWIN32 m:\Development\Source\Qt\src\corelib\animation\qabstractanimation.h -o tmp\moc\release_shared\moc_qabstractanimation.cpp

It crashes with this backtrace:

#​0 0x000000000049a3d5 in QBasicAtomicInt::deref (this=0x10)
#​1 0x0000000000000010 in ?? ()
#​2 0x00000000004a24d5 in QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::operator= (this=0x521110, other=...)
#​3 0x00000000004a20c1 in QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::clear (this=0x521110)
#​4 0x00000000004ace75 in QCache<QRegExpEngineKey, QRegExpEngine>::clear (this=0x521100)
#​5 0x00000000004ad249 in QCache<QRegExpEngineKey, QRegExpEngine>::~QCache (this=0x521100)
#​6 0x00000000004ad221 in QCache<QRegExpEngineKey, QRegExpEngine>::~QCache (this=0x521100)
#​7 0x0000000000468fac in global destructors keyed to a ()
#​8 0x0000000000493dc5 in __do_global_dtors ()
#​9 0x0000000000a62350 in ?? ()
#​10 0x0000000000000029 in ?? ()
#​11 0x0000000000000000 in ?? ()

I tried getting more out of it, but failed :(

[rubenvb]

I went digging in Qt sources, and the function both programs crash in is this one in src/corelib/arch/qatomic_i386.h:

inline bool QBasicAtomicInt::deref()
{
return q_atomic_decrement(&_q_value) != 0;
}

with this asm bit in src/corelib/arch/i386/qatomic_i386.s:

.align 4,0x90
.globl q_atomic_decrement

q_atomic_decrement:
movl 4(%esp), %ecx
lock
decl (%ecx)
mov $0,%eax
setne %al
ret
.align 4,0x90
.type q_atomic_decrement,@function
.size q_atomic_decrement,.-q_atomic_decrement

Maybe this asm is being misassembled by clang, or there is some bug in it that GCC and MSVC misuse or miss. I'm going to try a 32-bit clang with 32-bit mingw-w64 to see if this is a 64-bit Windows problem.

[rubenvb]

Negate the last bits of code. They're probably not the ones used. The ones used are all in this file:

http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/arch/qatomic_windows.h

Just search for "deref" and you'll find the function where the backtrace ends/begins. This is way above my knowledge, but should help anyone interested...

[rubenvb]

The qmake crash is also present on x86 (32-bit). moc's backtrace for the same invocation as before:

0x00478b49 in QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::operator= (this=Unhandled dwarf expression opcode 0xe5
)
(gdb) bt
#​0 0x00478b49 in QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::operator= (this=Unhandled dwarf expression opcode 0xe5
)
#​1 0x00478815 in QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::clear (this=0x28fe48)
#​2 0x00458b24 in global destructors keyed to a ()
#​3 0x00473712 in __do_global_dtors ()
#​4 0x0028feb4 in ?? ()
#​5 0x769f36bb in ?? ()
#​6 0x00401531 in __tmainCRTStartup ()
#​7 0x755433ca in ?? ()
#​8 0x77019ed2 in ?? ()
#​9 0x77019ea5 in ?? ()
#​10 0x00000000 in ?? ()

qmake's backtrace:

0x0041a34b in global destructors keyed to a ()
(gdb) bt
#​0 0x0041a34b in global destructors keyed to a ()
#​1 0x005b9f42 in __do_global_dtors ()
#​2 0x0028feb4 in ?? ()
#​3 0x769f36bb in ?? ()
#​4 0x00401531 in __tmainCRTStartup ()
#​5 0x755433ca in ?? ()
#​6 0x77019ed2 in ?? ()
#​7 0x77019ea5 in ?? ()
#​8 0x00000000 in ?? ()

This seems more informative :)

mingw-w64 developer Kai seemed to think this was calling convention related. I guess CLang produces bad C++ object code for Windows right now.

[AaronBallman]

Correct, support for thiscall has not been rolled into the trunk at this time. There is a patch in the wild for it, however. When it gets rolled in, can you try your tests again?

[asl]

Correct, support for thiscall has not been rolled into the trunk at this time.
I don't think thiscall CC is in business here. It's not used for C++ stuff compiled by clang/gcc.

[AaronBallman]

I was thinking it may be thiscall because of comment#4: "mingw-w64 developer Kai seemed to think this was calling convention related. I guess CLang produces bad C++ object code for Windows right now."

But you're probably right -- it's a longshot.

[AaronBallman]

thiscall support was added in 151122 and 151123, so it might be worth taking another stab at this just in case.

[llvmbot]

I debugged the problem with gdb and i686-w64-mingw32 build of qmake with "-O0 -ggdb3" flags. For qmake the bad code is generated through an function local static variable of type QString! I tracked the code to the assembly code. It seems clang is generating bad code for the global_destructors function!
Function local static variables are first initialized if the function is called the first time. This is guarded through clang with an flag so its only initialzed once. But in the global_destructors function clang implicit generates, the destructor of the object is called without checking that it was created though an constructor call! But this is necessary for local statics because the function can happen never to be called so that the object is never constructed!

Pseudo assembler code generated for local statics in qmake:
bool constructed = false;
QString a; // not contructed here. only exists in memory with uninitialzed data

function f()
{
if (!constructed)
call a::a(); // constructor call only once through guard "constructed"
constructed = true;
}

function global_destructors()
{
call a::~a(); // destructor without checking. tries to delete internal data pointer that does not exist
}

[llvmbot]

clang patch for -fno-use-cxa-atexit
Lemme know if this patch improved you.
I will propose it soon at cfe-commits.

[asl]

Function local static variables are first initialized if the function is called
the first time. This is guarded through clang with an flag so its only
initialzed once. But in the global_destructors function clang implicit
generates, the destructor of the object is called without checking that it was
created though an constructor call! But this is necessary for local statics
because the function can happen never to be called so that the object is never
constructed!
Will you please attach the preprocessed source and the generated asm?

[llvmbot]

Preprocessed cpp and assembly file for qmake

[llvmbot]

I forgot to mention the function and variable names:
function -> QMakeProject::isActiveConfig
local static -> static QString spec;

Labels in the asm to search for:
__ZZN12QMakeProject14isActiveConfigERK7QStringbP4QMapIS0_11QStringListEE4spec
__GLOBAL__D_a
LBB133_19

[llvmbot]

I try to test this but i'm building clang for the first time on windows with cmake. So it will take time if i get it to compile.
Maybe Ruben can apply this patch in his build and test it with qt to get done faster.
But i'll try my very best, because i would like to see clang on windows and the only importend thing for me so far is the qt framework.

[llvmbot]

Ok i got clang compiled with cmake on windows. It's not exactly the build ruben does but i think its ok (The binary .exe files are bigger but the static libraries are the same).
I compiled qmake with that clang and it seems the segfault is gone with that patch applied! The assembler generated code now contains calls to the atexit function.