Qt5 Qtwebkit encounter an "StackHash_0a9e" crash with Windows 7+ VS2012
-
I have the same problem with msvc 2012 and x86.
Every application crashes instantly.I compiled everything with msvc 2012 from the sources.
The x64 builds are working without any problem.Did you got it running with msvc 2012 in the meantime?
-
Not yet. I stopped using vs2012. The purpose I tried to compile Qt under 2012 , is, taking a look at NEW C++ 11 standard features, and for a better performance.
Now, I'm not quite sure to upgrade my project to VS2012, for two reasons:
- Every GUI app using QWebKit will fail under release version.
- Visual C++ 2012 compiler and linker seems not only a bit slower , but more memory-greeding when building such a huge project. The linker often encounted an "Out of memory" error when dealing with 1GB-size libs , eg, webcore. This is mostly due to memory fregment caused by frequently mem-alloc-free, an reboot and re-nmake can fix that problem.
- new C++ 11 standard in VS2012 can mostly be replaced by Qt based features, and new binding style signal-slots is also avalible in VS2010.
-
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) -
Same here, all components are compiled with VS 2012 + QT from git. and QWebView crashes instantly...
-
Exact same problem here, on Win7 x64 MSVC 2012, Qt build from git. Probably this is the reason why there is no prebuild download? ;)
Another thing, on the first build try I enabled LTCG, the build system tries to build an static webkit library and fails on it's size (>2 GB I guess).
And I don't think ICU 5 for MSVC 2010 should pose any problems, C interface should be compatible, else interfacing with any system library would be a problem too.
-
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.