Qt5 Qtwebkit encounter an "StackHash_0a9e" crash with Windows 7+ VS2012
-
OS: winserver_2003 64bit + Oracle VMbox + windows 7 32bit
Complier: VS2012 .
source Pack: qt-everywhere 5.0, extract zip package to d:\Qt\temp
configure paras:
-
-icu (using ICU4C 50 prebuild vs2010, vcredist already installed) -
-openssl (Compiled with vc2012) -
-debug-and-release, -
-prefix D:\Qt\qt5.0.0\5.0.0\msvc2012
sqllite has ben extracted to d:\Qt\sqllite_folder.
- I started nmake in Visual Studio 2012 cmdline, everything went ok, "nmake install" put everything well ok.
- HOWEVER, when I start qtassistant, a crash box poped up, os said "StackHash_0a9e". I tried to start a in-time debugger, it seems that the app went dead in Qt5WebKit.dll, with a bad pointer operation.
- Then, I find that not only qt-assisitant , but ALL of the applicaitons using release version "Qt5Webkit" could fire this error , (debug version is OK). we will mostly get an empty-white main-frame before app dead.
- Is there anyone-else encoutered this problem?
- I googled this problem, seems that some popular Video GAMEs could cause this problem. OpenGL? Network? Unicode and UTF-8 issues? so I'm now trying to roll ICU50 back to ICU49 , and a -opengl desktop conf option, remove -openssl, configure and rebuild Qt5 with force-debug-info again. I hope that debug symbols in release version can give me a clear call-stack when crash happen.
-
-
Make sure everything is build with the same compiler. Using different compiler versions does cause all kinds of crashes!
-
eer, ICU is vc2010 based, may be a rebuild in vc2012 can fix that problem, I'll try agan
-
I spent more than two days to re-compile the code with different configure options. At first I built openssl, ICU4C49 under VS2012, then tried to combine different paraments , with or without -openssl, -opengl desktop。 Unfortunately nothing changed.
The text below is the call stack when assistant.exe failed to start. (Another problem , is, -force-debug-info option makes no debug info for release versions, no PDB file founded).
I notice that there is a ZERO size malloc options, which shall be the reson for this crash.
00000000() Unknown
[Frames below may be incorrect and/or missing]
Qt5WebKit.dll!6ab89aaa() Unknown
Qt5WebKit.dll!6abfd1ea() Unknown
Qt5WebKit.dll!6ae747ec() Unknown
Qt5WebKit.dll!6aae6221() Unknown
Qt5WebKit.dll!6a93a872() Unknown
Qt5WebKit.dll!6a93b21b() Unknown
Qt5WebKit.dll!6a93bfdd() Unknown
Qt5WebKit.dll!6a93bc54() Unknown
Qt5WebKit.dll!6a6fe7d0() Unknown
Qt5WebKitWidgets.dll!6eec3723() Unknown
Qt5WebKitWidgets.dll!6eec7732() Unknown
Qt5Widgets.dll!6b6d4cb0() Unknown
Qt5WebKitWidgets.dll!6eecaef6() Unknown
Qt5WebKitWidgets.dll!6eec57db() Unknown
Qt5WebKitWidgets.dll!6eecea62() Unknown
assistant.exe!00369447() Unknown
assistant.exe!00365db3() Unknown
assistant.exe!00368a74() Unknown
msvcr110.dll!malloc(unsigned int size=0) Line 91 Crash man be caused here??
Qt5Widgets.dll!6b6d4354() Unknown
Qt5Widgets.dll!6b6c926b() Unknown
assistant.exe!00368f25() Unknown
assistant.exe!00367e99() Unknown
assistant.exe!00368331() Unknown
assistant.exe!00357bc3() Unknown
Qt5Core.dll!6cc21ca3() Unknown
assistant.exe!0034e7fe() Unknown
kernel32.dll!75bf3c45() Unknown
ntdll.dll!772037f5() Unknown
kernel32.dll!75bfed38() Unknown
kernel32.dll!75bfed38() Unknown
now I'm building the same package under vc2010.
-
I built it under vc2010, everything is OK!
-
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.
-
#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.
