@JonB sorry for long reply
debug size is 29.5M
release size is 18.3M
Free memory always a more than needed PC have 16Gb ram. Also i checked swap, swap is newer used for last days. So problem is not here.
Next step i will check all dlls one by one in tes Win32 pure C application, maybe problem is here.
no cpecific initial code ... but as u can see a lot of dependencies.. In linux exist LD_PRELOAD key but there is no solution for windows i found.
Thanks for response, if i found any solution or reason i'll report it here.
Desktop QT 5.6.2 MinGW 32bit -> can make normal win32 apps in 32 bit. Run on win 10 64 bit too ( as 32 bit)
Desktop QT 5.6.2 MSVC2013 32bit. -> 32 bit, you must install compiler yourself. VS 2013 ONLY ( runs on 64 bit too)
Desktop QT 5.6.2 MSVC2013 64bit -> 64 bit, you must install compiler yourself. VS 2013 ONLY ( runs ONLY 64 bit )
Desktop QT 5.6.2 MSVC2015 32bit -> 32 bit, you must install compiler yourself. VS 2015/17 ONLY ( runs on 64 bit too)
Desktop QT 5.6.2 MSVC2015 64bit -> 64 bit, you must install compiler yourself. VS 2015/17 ONLY ( runs ONLY on 64 bit)
Desktop QT 5.6.2 for Universal Windows Patform 32bit Not a Desktop app. WinRT only app
Desktop QT 5.6.2 for Universal Windows Patform 64bit Not a Desktop app. WinRT only app
Sounds to me you can just use mingw. for both 32/64 bit unless you want app to be 64 bit ?
I have also test the Registry Key changes, but doesn't have any impact.
By the way, I just realize that the XP build of my application is using ANGLE (because OpenGL is not supported) and Windows7 is using OpenGL.
By forcing Windows7 to use ANGLE, TeamViewer is working also with Windows7 :)
Slightly related, is QCA supported and updated? The last thing you'd want is to use an out of date cryptographic library.
I normally use Crypto++ but libcrypto of OpenSSL is also very good (if you don't mind messing with C)
It is still active, looking at the the git (https://cgit.kde.org/qca.git/) the last commit was in 2017-09-30 (some months ago, but it isn't dead).
I had also been looking at Crypto++, but ended up settleing for QCA for no pacticular reasons. And I wouldn't mess with C, I'm still even just a C++ newbie afterall ;) QCA can also use OpenSSL btw.
Nowadays the software renderer for WebGL works fine. I wonder if there is some easy way to detect if the video adapter is affected (probably intel && being "old") and if that's the case, to switch to software renderer, at run-time - maybe before initializing QApplication? in order to pass --enable-webgl-software-rendering parameter programmatically.
I've been digging around for the last couple of days trying to find the root cause of the issue and then it turned out that even the simplest Qt Quick application will crash with the same stack trace as long as it displays some text. Likewise none of the examples that are shipped with Qt (accessible through the Welcome -> Examples screen in Qt Creator) work, they simply crash on startup.
Would it be safe to assume it's a bug with Qt 5.9.1 built using MSVS 2017 (VC14.1)?
How do I even proceed now? Do I report it on the issue tracker?
Hi, googling finds many with the same problem, for example here
Just guessing, but perhaps you could try some of the suggestions in there...
Thanks for the link.
It seems this issue doesn't even solved in Stack Overflow :(
Any way, I did some of the suggestions mentioned in it.
Installed all redistributable package of x86 (cuz I built my app using Qt mingw53_32) for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist)
Installed all redistributable package of x64 for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist)
Nothing changed still see my app crashes without any logical reason!
Now I'm very sad because I can run my app only if I installed Qt on my machine which is impractical solution for deploying my app.
Then, AFAUI, you have all what you need to continue. If implementing the proxy model looks daunting start by just a custom QAbstractItemModel with a QListView and once you have what you want you can go with the proxy and the shifting I suggested before.
Right, the library doesn't seem to be very Windows friendly. It assumes the pointers to GL functions resolved and available in global scope, which is not how it usually works on this platform. Moreover it seems to force ANGLE and OpenGL ES (or at least tries to) on Windows in the .pri file, but then is inconsistent in how it checks for that.
I'd say contact the authors and ask them to fix the Windows parts.