Qt5 Qtwebkit encounter an "StackHash_0a9e" crash with Windows 7+ VS2012
-
The same here:
Qt 5.0.1, Win8 Pro 64bit, MSVC 2012Webkit crashes reproducible.
-
Amendment: assistant.exe works as expected, but not a programm using Webkit.
-
[quote author="manuel.gysin" date="1358629363"]Thanks a lot for you very usefully answer! :)
Can I ask you a last question? Did you created a bug report for the problem?
If yes, can you please provide me the link? (I cant find anything related to this in the bug tracker)[/quote]Of couse! My pleasure! I'm not quite sure about this problem, maybe, Chinese locale or special hardware/software envs can cause this. I'll try it later under raw eng windows 7, If the error still occur, I'll push a bug report.
-
Sounds good, I wouldn't know how to start a bugreport on this case. Tried to find one, but I don't think there is one.
Got a slow computer, release build takes half a day already. I built 4.8.4 and 5.0.1 in x86 and amd64 archs as release and they fail all the same. 4.8.4 doesn't even build without a patch.
On a side note I don't think it's good for Qt's current makers to say it would be plain possible to build on MSVC 2012, telling the fact there are no downloads for it would be build bot related, when in reality either Qt or the compiler just aren't able to produce a working kit.
Could have spared me hours of rebuilding :p
-
Ah I've got Update 1 on MSVC 2012 so maybe that matters, too. For anyone trying to triage the problem and putting up a bug report.
-
This bug is causing the problem: https://bugs.webkit.org/show_bug.cgi?id=90008 it is still not fixed in 5.0.1
I've put an updated copy of TextEncodingRegistry.cpp that works around the bug here: http://pastebin.com/hMfQH9i7
-
Thank you. I looked at this bug report before and didn't link it to our issue here.
4.8.4 version is different,
(removed link to it)
this patch works for 4.8.4. I'm not so sure that I didn't broke something but assistant doesn't crash anymore.
Hope the patch format is fine. First time ever :D
-
Its definitivly not right and fracks encoding, so don't use my patch. Sorry.
-
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: