Qt5 Qtwebkit encounter an "StackHash_0a9e" crash with Windows 7+ VS2012
-
I wasn't sure a porper bug report was sent, so here is the bug report:
https://bugreports.qt-project.org/browse/QTBUG-29719
lets hope it will be fixed in 5.0.2 (~end of feb?)
Torben
-
Now it is a confirmed bug an raised to critical:
-
Marked closed, though my build from git just crashes as hard as before with or without the patch and with 2012.2 CTP 4 installed, for x64.
My compiler's _MSC_FULL_VER is lower then the one in the patch, seems MS doesn't fix the x64 compiler?
170051106 vs. 170050727 x64, the x86 version is 170060223.
Seems to me there is more then one bug, and then made worse by different behaviour betweens windows arch's.
-
Hi, thanks for the feedback! We should investigate this issue as soon as possible to get the fix into Update 2 before it is released!
First: What did you compile? Qt 4.8.4 with the patch you listed above? Or Qt 5.0.1 stable or maybe even latest build of 5.0.2 ?
Sorry, the version listing above is not clear for me.
Can you list what the MSVC_FULL_VER is for:- VS 2012.1 x86
- VS 2012.1 x64
- VS 2012.2 x86
- VS 2012.2 x64
When building Qt 5.0.2 nightly build (release branch), please be aware that it contains a workaround fix, but that will be removed in future versions to maintain the code clear.
So building Qt 5.0.1 might be a good benchmark to test if the bug is fixed on the VS 2012.2 side.
Of course we have to verify that in x86 and x64.If I update to VS Update 2 CTP4, do I have to rebuild all Qt dependencies like OpenSSL, or is the framework set basically the same ( v110 / v110_xp ) and "only" bugfixed?
Thanks, Torben
-
I'll collect the _MSC_FULL_VERs now and post a longer answer with them.
-
Hi,
I have installed update 2 CTP4 on my maschine, so here are my compiler versions:
VS 2012.1:
- x86 / x86_xp = 17.00.51106.1
- x64 / x64_xp = 17.00.50727.1
VS 2012.2:
- x86 / x86_xp = 17.00.60223.1
- x64 / x64_xp = 17.00.50727.1
You are right, at least the version number of x64 compiler is not increased in 2012.2 . Now I'll start to build Qt 5.0.1 in x86 and in x64 to test whether it crashes again also on my site (as you reported).
Torben
-
Hi Torben,
good idea, lets put forces together. And fine, know I can spare me the reinstalls and repairs of VS 2012 in my VM for that :D
The patch I posted further up is nonsense, ignore that.
I compiled Qt from git, cloned yesterday, it's tagged 5.0.2 though it didn't contain the patch thats in your Qt bug report. The Qt modules are in git's detached head mode, so if anyone needs the exact versions, please tell me how to collect the hash they point to and I post them.
I did compile OpenSSL 1.0.1c and ICU 50.1.2 with the VS 2012.2 CTP 4 compiler beforehand, compilation of them and Qt went through without problems. Everything in release mode for x64. The Qt tools seem to work alright, just QtWebkit does not.
If you build from command line for nmake you use the standard v110 "toolset", all the v110_xp thing does in visual studio is setup the usage of an older Platform SDK for include/libs and setting the linker to include XP as minimum runtime flag for the built executables. And that messes with Qt build, so Qt would have to have a changed mkspec mirroring the behaviour of v110_xp. I didn't do that. I think earlier Qt build 5.0.1 did set the pe image flags right in the first place (that should be enough for XP support), the last one did not set it any more.
If I had a faster computer at hand I'd be less reluctant to build and look at the sources. Funny thing is in the last days I made a clang/c++11 build for Qt in a Linux VM and that wasn't soo much waiting, neither that hard to understand whats going on, too (and works just fine with a handfull changes).
I gonne make a debug build today too, should take some hours before I can tell if I can get something sensible from that.
-
#Hm, short answer: you areright, it is still not part of Qt 5.0.2. At the moment Qt seems to be a bit messy, lots of bugs and trouble it cleaning it up..
I updated the bugreport which states the bugfix being part of 5.0.2 which is not true currently.
To conclude, we can use any Qt version out there to reproduce the bug since the workaround is not available in sources yet ;)
To v110 vs v110_xp:
You are right, basically only a different SDK is configured to be used and a differente subsystem is chosen.
I set up a simple vcvars.bat file to change to v110_xp (since I need it for my clients). It did not mess up console builds the procedure buiding Qt ist identical. and works like a charm. I just wantet to reassure myself that the compiler verisons on v110 and v110_xp are identical...I agree, I'm part of a two-headed developer team. My partner develops on linux and myself on windows. All clients are using Win. In Linux a full Qt build is done very fast. x times faster than on windows (but the MS Windows machine has 3x more cores and memory :( ) But we have to cope with that win specific problems - some has to build and deploy the final software.
I have to build ICU in 32 and 64 bit to be able to build Qt. Do I need openSSL for webkit?
Torben
-
Don't think you need openssl for testing, it's linked in weakly and really just called for ssl connections.
Ah and yet the linker flags are set for 5.02 as minimum subsystem version, so that did not change, as I thought earlier.
-
Okay, thanks.
In producive setup I use it only for SSL secured SQL connections.
I'll build ICU and Qt in 32 and 64 bit, I'll call you back once I have news.
-
My Qt from git doesn't want to build a debug version. I'll give up on that one. :s
-
Download the latest package from digia:
-
I built it with VS2012.2 CTP4 in 32 bit. The crash ist the same as before.
I think there is a big misinterpretation. Mirosoft announce the bug to be solved in the next compiler verison.
Update 2 is not a new compiler release but a IDE/ENVDEV version. Fixing bugs in the compiler would require them also to replace the redist filse. This would require a new file name version, which would be handled with a new toolset identifier (for example v120, released in mid 2013).
So at the end, I think we have to rely on a workaround on the Webkit side.
-
Thanks for investigation and support Torben, great that you do that.
I read the bug report's activities and I guess I know now why it's marked fixed while we see something different.
They just don't test if Qt's webkit actually works.
Beg it's the same reason we see, it takes ages to build it.
On another note I don't get why MS doesn't fix both compilers, it's not edgy black art in the specific part of webkit but perfectly valid code. Sure any bigger project must sooner or later see the compiler bugs. If they get to pinpoint it to the compiler is another question, sure.
Just horrible they didn't fix it in 2 updates. I mean people are supposed to be able to sell working software built with it right? MS is that I talk about here.
Qt with VC 2010 did also uncover a compiler bug, that was solved fast, first with an seperate update for the compiler and then I think officially in SP1.