Bug 44052 - [Qt] Crash on mingw-w64 in Qt Browser demo and Assistant
Summary: [Qt] Crash on mingw-w64 in Qt Browser demo and Assistant
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P4 Minor
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2010-08-16 03:37 PDT by vanboxem.ruben
Modified: 2011-01-27 10:57 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vanboxem.ruben 2010-08-16 03:37:59 PDT
see Qt bug http://bugreports.qt.nokia.com/browse/QTBUG-12808 for backtrace and info.

I stress that this crash was not present on the 17th of July (and all time before), nor in Qt 4.7 beta 2.
Comment 1 Andras Becsi 2010-09-13 09:54:15 PDT
The issue might have been fixed in https://bugs.webkit.org/show_bug.cgi?id=42818.
Could you please check whether the trunk works for you?
If so, then Simon should probably cherry-pick Ossy's patch into the corresponding QtWebKit2 branch on gitorious.
Comment 2 vanboxem.ruben 2010-09-13 12:22:25 PDT
I downloaded a nightly snapshot dated 13-9-2010 and got this error when building with Qt 4.7 from git (~11-9-2010):

perl WebKitTools\Scripts\build-webkit --qt
...
g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security -Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -O3 -frtti -fexceptions -mthreads -flto -DUNICODE -DQT_LARGEFILE_SUPPORT -DBUILDING_QT__=1 -DWTF_USE_ACCELERATED_COMPOSITING -DUSE_SYSTEM_MALLOC -DNDEBUG -D_HAS_TR1=0 -DBUILDING_QT__ -DBUILDING_JavaScriptCore -DBUILDING_WTF -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I"..\..\..\..\Qt\include\QtCore" -I"..\..\..\..\Qt\include" -I"..\..\..\JavaScriptCore" -I"..\..\..\..\WebKit" -I"..\..\..\JavaScriptCore\assembler" -I"..\..\..\JavaScriptCore\bytecode" -I"..\..\..\JavaScriptCore\bytecompiler" -I"..\..\..\JavaScriptCore\debugger" -I"..\..\..\JavaScriptCore\interpreter" -I"..\..\..\JavaScriptCore\jit" -I"..\..\..\JavaScriptCore\parser" -I"..\..\..\JavaScriptCore\pcre" -I"..\..\..\JavaScriptCore\profiler" -I"..\..\..\JavaScriptCore\runtime" -I"..\..\..\JavaScriptCore\wtf" -I"m:\Development\x64\WebKit\JavaScriptCore\wtf\symbian" -I"..\..\..\JavaScriptCore\wtf\unicode" -I"..\..\..\JavaScriptCore\yarr" -I"..\..\..\JavaScriptCore\API" -I"..\..\..\JavaScriptCore\ForwardingHeaders" -I"generated" -I"..\include\QtWebKit" -I"..\..\..\JavaScriptCore\pcre" -I"m:\Development\x64\WebKit\WebKitBuild\Release\JavaScriptCore\tmp" -I"..\..\..\..\Qt\include\ActiveQt" -I"release" -I"..\..\..\JavaScriptCore" -I"." -I"..\..\..\..\Qt\mkspecs\default" -o obj\release\ExecutableAllocatorFixedVMPool.o ..\..\..\JavaScriptCore\jit\ExecutableAllocatorFixedVMPool.cpp
..\..\..\JavaScriptCore\jit\ExecutableAllocatorFixedVMPool.cpp:35:22: fatal error: sys/mman.h: No such file or directory
compilation terminated.

sys/mman.h isn't present for a mingw toolchain... perhaps some other build steps are needed, but it seems Platform.h has changed quite a bit since I had it modified for mingw-w64... Is JIT now enabled for 64-bit Windows + GCC (mingw-w64)?

I must be honest and say that the problem I reported here, went away somewhere in September, and Qt 4.7 Webkit does not exhibit this problem.
Comment 3 vanboxem.ruben 2010-09-18 05:20:50 PDT
I have just tested Qt at commit fe350ca756df6392b3d0b7840351fccc89f9ef6f (September 9) and the crash does not occur. It was a change somewhere after 9-9.
Comment 4 Andras Becsi 2010-09-18 05:26:56 PDT
Since the (In reply to comment #3)
> I have just tested Qt at commit fe350ca756df6392b3d0b7840351fccc89f9ef6f (September 9) and the crash does not occur. It was a change somewhere after 9-9.

Closing this bug as invalid then since the problem no longer exists.
Comment 5 vanboxem.ruben 2010-09-18 05:29:00 PDT
Extremely sorry for the confusion, but my previous message was misunderstood; the crash reappeared somewhere between Qt 4.7 at fe350ca756df6392b3d0b7840351fccc89f9ef6f and current master. It also existed after the 17th of July. This crash has returned, and the bug is not gone.

Sorry.
Comment 6 Andras Becsi 2010-09-18 05:30:45 PDT
(In reply to comment #5)
> Extremely sorry for the confusion, but my previous message was misunderstood; the crash reappeared somewhere between Qt 4.7 at fe350ca756df6392b3d0b7840351fccc89f9ef6f and current master. It also existed after the 17th of July. This crash has returned, and the bug is not gone.

Sorry for the confusion.
Comment 7 vanboxem.ruben 2010-09-21 07:11:40 PDT
After many rebuilds of Qt, trying out different options, it seems a release build with -flto enabled produces a crashing browser example. This may make it a GCC optimization bug, but I will still try to get more info for this case. To this effect, I have modified mkspecs/win32-g++/qmake.conf:

QMAKE_CFLAGS_RELEASE = -g -O2
QMAKE_CFLAGS_LTCG = -flto
...
QMAKE_LFLAGS_LTCG = -flto -fwhopr=2

This, together with "configure -ltcg..." enables link time optimization for gcc like it does for MSVC. The stacktrace I get from this is extremely unhelpful:

#0  0x000000000165d02d in QWebInspector::qt_metacast(char const*) () from M:\Development\x64\Qt\bin\QtWebKit4.dll
#1  0x00000000066ddcf0 in ?? ()
#2  0x0000000003f82a18 in ?? ()
#3  0x0000000000000000 in ?? ()

To get more debug info, I am recompiling with debug flag "-ggdb3", and removing the linker command "-Wl,-s" from QMAKE_LFLAGS_RELEASE which apparently still ripped out all debug info.

I will post the more informative backtrace here when I get it. Perhaps someone with a linux install can test and see if lto is also problematic there, then it is not a mingw-dependent problem.
Comment 8 vanboxem.ruben 2010-10-12 06:55:25 PDT
I have compiled all of Qt with "-g2 O2 -flto..."

This is in effect a debug release build with lto enabled. This last bit does not per se cause the crash, but I did it anyways. Debug level 3 caused an ld.exe crash (probably the output lib was too large)

The backtrace for the browser demo is this:

#0  performMatch (ovector=<value optimized out>, length=<value optimized out>, position=<value optimized out>, startOffset=<value optimized out>, s=..., r=0x39625590, this=<value optimized out>) at m:/Development/Source/Qt/src/3rdparty/webkit/JavaScriptCore/runtime//RegExpConstructor.h:117
#1  JSC::stringProtoFuncReplace (exec=0x39140148, thisValue=..., args=...) at m:\Development\Source\Qt\src\3rdparty\webkit\JavaScriptCore\runtime\StringPrototype.cpp:349
#2  0x0000000080df02b8 in JSC::Interpreter::privateExecute (this=0x369c90d0, flag=JSC::Interpreter::Normal, registerFile=0x369c90e8, callFrame=0x391400e0, exception=0x22a490) at m:\Development\Source\Qt\src\3rdparty\webkit\JavaScriptCore\interpreter\Interpreter.cpp:3437
#3  0x0000000080df91e6 in JSC::Interpreter::execute (this=0x369c90d0, program=0x369cdec0, callFrame=0x36abcd88, scopeChain=0x36abcf70, thisObj=0x36a00000, exception=0x22a490) at m:\Development\Source\Qt\src\3rdparty\webkit\JavaScriptCore\interpreter\Interpreter.cpp:623
#4  0x0000000080de3939 in JSC::evaluate (exec=0x36abcd88, scopeChain=..., source=..., thisValue=...) at m:\Development\Source\Qt\src\3rdparty\webkit\JavaScriptCore\runtime\Completion.cpp:62
#5  0x0000000080524bd5 in WebCore::ScriptController::evaluateInWorld (this=0x369065f8, sourceCode=..., world=0x35a66b40) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\bindings\js\ScriptController.cpp:127
#6  0x00000000805256e1 in WebCore::ScriptController::evaluate (this=0x369065f8, sourceCode=<value optimized out>) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\bindings\js\ScriptController.cpp:153
#7  0x0000000080535d22 in WebCore::ScriptController::executeScript (this=0x369065f8, sourceCode=...) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\bindings\ScriptControllerBase.cpp:60
#8  0x00000000807df44b in WebCore::HTMLTokenizer::scriptExecution (this=0x36957760, sourceCode=..., state=...) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\html\HTMLTokenizer.cpp:580
#9  0x00000000807e5392 in WebCore::HTMLTokenizer::executeExternalScriptsIfReady (this=0x36957760) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\html\HTMLTokenizer.cpp:2073
#10 0x00000000808433c2 in WebCore::CachedScript::checkNotify (this=0x36a92210) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\loader\CachedScript.cpp:106
#11 0x0000000080890ce2 in WebCore::Loader::Host::didFinishLoading (this=0x36a92730, loader=0x36a94010) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\loader\loader.cpp:399
#12 0x00000000808b2611 in WebCore::SubresourceLoader::didFinishLoading (this=0x36a94010) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\loader\SubresourceLoader.cpp:184
#13 0x0000000080acc982 in WebCore::QNetworkReplyHandler::finish (this=0x36a94dd0) at m:\Development\Source\Qt\src\3rdparty\WebKit\Webcore\platform\network\qt\QNetworkReplyHandler.cpp:261
#14 0x0000000080acd66c in WebCore::QNetworkReplyHandler::qt_metacall (this=0x36a94dd0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x22b580) at tmp/moc/release_shared/moc_QNetworkReplyHandler.cpp:84
#15 0x0000000001a43f1a in QMetaObject::activate (sender=0x36a7a090, m=0x70000460, local_signal_index=1, argv=0x0) at m:\Development\Source\Qt\src\corelib\kernel\qobject.cpp:3272
#16 0x0000000036a7a090 in ?? ()
#17 0x0000000036a7a6b0 in ?? ()
#18 0x0000000036a7a680 in ?? ()
#19 0x0000000036a7a680 in ?? ()
#20 0x0000000001a430de in QObject::disconnect (sender=0xffffffff, signal=<value optimized out>, receiver=0xffffffff, method=<value optimized out>) at m:\Development\Source\Qt\src\corelib\kernel\qobject.cpp:2670
#21 0x0000000036a7aa20 in ?? ()
#22 0x0000000036a94dd0 in ?? ()
#23 0x0000000036a7aa20 in ?? ()
#24 0x0000000036a7a2e0 in ?? ()
#25 0x0000000500000007 in ?? ()
#26 0x000000000022b580 in ?? ()
#27 0x00000000000286a0 in ?? ()
#28 0x000000000022b570 in ?? ()
#29 0x000000000022b570 in ?? ()
#30 0x0100000000000000 in ?? ()
#31 0x000000000022b560 in ?? ()
#32 0x000000006ceceed6 in libgcc_s_sjlj-1!_Unwind_SjLj_Register () from M:\Development\mingw64\bin\libgcc_s_sjlj-1.dll
#33 0x0000000977152940 in ?? ()
#34 0x0000000000000000 in ?? ()
Comment 9 vanboxem.ruben 2010-12-23 14:27:03 PST
Any news on this issue? I have done the best I can to provide providable information. If there's anything else, please ask.

Thanks!
Comment 10 Benjamin Poulain 2011-01-03 05:23:44 PST
(In reply to comment #9)
> Any news on this issue? I have done the best I can to provide providable information. If there's anything else, please ask.

This is a P4, nobody is working on this.

Mingw-w64 is not officially supported, and here it looks like the bug could be in the compiler. I think your best chance to see this fixed is to submit a patch :)
Comment 11 vanboxem.ruben 2011-01-27 10:57:57 PST
This bug seems to have fixed itself. I am not experiencing the issue anymore and can run GCC 4.5-built Qt WebKit apps just fine.