This is very interesting crash and I think it should be considered as Qt bug. This problem arise only under very special circumstances. But one after another.
You will identify this problem when your application stopped/exited immediately after the start without any visible error message. It looks like the application isn't executed at all. When you check application log (Computer -> manage -> Event viewer -> Windows logs -> Application), you will see Error logs:
The most interesting part of this log is crash location: ntdll.dll
At first sight it seems like some problem inside the windows. But the opposite is true, the problem (as almost always) is inside your app ;-).
As the next step, you can try to debug this executable via Visual Studio to see what happens inside. Simply open executable as project together with .pdb files and execute it. Now you can see that application is correctly executed but crashes as soon as it touches Qt library. The location of crash is inside ntdll.dll in RtlHeapFree() function.
So the problem is inside the Qt, right? Almost true, but not for the 100%. When I tried to run this application on computers of my colleagues, everything works ok. So why the application doesn't work on my computer too?
The problem is in new Qt5 plugin system. Besides the common Qt5*.dll files which are loaded immediately after the application start, Qt5 is also loading plugins/platform-plugins dynamically when the application is executed. To locate this plugins, Qt5 uses following method to identify directories where to search for plugins:
For some strange reason this library returns as first directory path where Qt5 libraries were compiled and after that location based on the executable. So if your Qt5 path is C:\Qt5, this will be the first path where all plugins are searched for, no matter if the correct version of plugin is located in APP\plugins or APP\platforms. **I think this is serious bug in Qt5**.
Where is the problem?
And here we're getting to the core of the whole problem.
**If application is compiled on computer with one compiler and used on second computer which contains the same path to which original computer has installed Qt, the application will load all plugins from your folder instead of itself folder.**
In case your computer will contain different version of Qt, different compiler or different platform, application loads incorrect libraries and crashes. Completely, silently and without easy way to determine what's wrong.
The solution is simple, but it isn't achievable from outside of the Qt library. It would be necessary to Qt as first tried to load libraries from application directory. And only if no plugins were found in application directory, the application would try to search for plugins in Qt directory.
Qt change solution
The simplest way how to fix this issue inside the Qt library would be to rename/update appendApplicationPathToLibraryPaths function to prependApplicationPathToLibraryPaths and change
Unfortunately it isn't possible to simply change this behavior from your app. All of these operations happen directly in QCoreApplication constructor so if you try to change it after, it's too late.
The temporary solution before this problem will be resolved is to reinitialize library paths before QCoreApplication is initialized. It's necessary to clean libray paths, compute new paths and re-initialize QCoreApplication::libraryPaths before QCoreApplication object is initialized. This can be done in main.cpp of your application before you will create QApplication/QCoreApplication object.
It's not a nice solution, but it works. I tried to report this issue also to bugreports.QtProject, so maybe in later version this will be fixed.
For debugging purposes it's a good idea to keep .pdb files also for release version of your libraries. Unfortunately in default configuration Qt library doesn't generate .pdb files. It's a not big deal, create .pdb files for release version it's pretty simple.
1) Add compilation flags to .pro file
The easiest way how to create pdb files is pass /Zi switch to compiler and /Debug to linker.
2) Solution via mkspec
As pointed out in this QtProject article, another way is to edit mkspec so any future compilations will have this option turned on. It's necessary to modify correct mkspec file, for example
and add following lines (it should be sufficient to add only /Zi and /Debug switch):
One of very useful feature of Visual Studio is custom variables views. It's possible to configure own views to each of your class. For this, VS2013 (and VS2012) uses .natvis files located in following directories:
Files are stored in common .xml format and has following format:
Debugging .natvis files
Visual studio contains a way how to catch syntax and logical errors in natvis format. All warnings/errors can be displayed to Visual Studio output panel by specifying following registry key to "1".
Note: It's necessary to restart Visual studio to turn on this feature
It's necessary to configure which parameters are passed to fast-cgi application from nginx server. For this purposes serves fastcgi_param keyword. It's a good practice to keeps all fastcgi params together. For this purposes nginx has fastcgi.conf file. This file already contains most of useful fastcgi_param bindings.
To include this file use include statement:
How to pass custom headers to fast-cgi app
Default configuration pass only default headers to fast-cgi. It's necessary to add few more configurations statements:
After that headers are passed as HTTP_* parameters:
There are two ways. When web-server supports fast-cgi you will be able to connect fast-cgi directly with web-server via configuration files. In all other cases fast-cgi offers cgi-fcgi executable as bridge between webserver and your app. More info about both these approaches you can find here http://www.fastcgi.com/devkit/doc/fcgi-devel-kit.htm#S4.
Working way how to get fastcgi apps working
None of two ways described in previous article and in official documentation works for me on windows. I wasn't able to get cgi-fcgi or spawn-fcgi running. First mentioned crashed everytime app tries to initialize STD_OUT, the second one isn't possible to compile it because of missing unistd.h header.
Fortunately there is one more way. FCGI library offers one more way how to utilize FCGI mechanism. It's necessary add two more lines to example above and everything works perfectly.
After this change application initialize listening port and waits for incoming data. All you need to do is directly execute the app.
Configure nginx to connect with fast-cgi
This step compared to previous ones is pretty easy. You need to tell nginx server what and where to pass. Open file nginx.conf and add following statement:
fastcgi_pass statement forward all requests to localhost:9345 address. Now when you start your nginx server, everything should work as expected.
bind() to 0.0.0.0:80 failed
This error is caused by another application which uses port 80. In my case it was Skype which automatically uses port 80.
FastCGI comes with Win32 project for VisualStudio6. Unfortunately when you try to open it in VisualStudio2010 the project will be corrupted. To correctly compile it for VS2010 it's necessary to download library sources, get patches from cybozu.co.jp site and apply it.
Today my Visual Studio 2010 started to execute my application super slowly. When I tried to execute my application (without any changes in source-code) the delay between "Start Debugging" and application start was about one minute.
I know that too many breakpoints or breakpoints in templates could caused this, but I don't see any breakpoint in my Breakpoints window.
But as I have found that the problem was really caused by breakpoints. In some special cases - when you're using some external tools to modified your project file (.sln/.vcxproj) - breakpoints can disappear and begin to make a trouble (I'm using Qt qmake to update my project based on .pro files.)
The solution is pretty easy. Use **Delete All Breakpoins** from Debug menu:
[caption id="" align="aligncenter" width="637"] The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.dll[/caption]
Today we received report from one of our customers about problem with our ORM Designer on WindowsXP - 32bit. Our latest version returns following error:
The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.dll
**The problem is that GetTickCount64 doesn't exists in XP system**.
It's necessary to compile your application (and any library which uses GetTickCount64) with correct **WINVER** and **_WIN32_WINNT **defines value. List of WINVER values for all Windows version can be found here.
You can define these values in your resource.h file:
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
or add it to a project property -> C/C++ -> Preprocessor -> Preprocessor Definitions:
If you want to define these values automatically in Qt project, add following lines to your .pro file:
#Windows XP compatability
DEFINES += "WINVER=0x0501"
DEFINES += "_WIN32_WINNT=0x0501"
One of tool we're using requires **msdia80.dll** file. Unfortunately this DLL is available only inside the VS2005 installation / redistributable pack. When you execute **dump_syms.exe** without this file, you will receive following message:
One solution is to install Visual C++ 2005 Redistributable Package. Another way is download only msdia80.dll file and register it manually by using:
Also the issue may be the result of Aggressive Link State Power Management (ALPM) on the PCI-Express bus negotiating a lower power state for the link between the controller and disk when there is no activity. When ALPM works, disk requests are queued, the serial link revived, and the queued requests are sent to the relevant disk; this requires a disk that supports ALPM.
Integration of Google breakpad on any platform is really challenge. I didn't figure out how to do it by using recommended ways. So I did it my way ;-)
Create your own Qt project
As first thing I did when integrating Qt and Breakpad is creation of my own .pri file. I manually add all required files from Breakpad one-by-one, starting with src/platform/exception_handler continuing with all files included in previous ones. The complete .pri file you will find at end of this post.
After that I created simple CCrashHandler (inspired by qt-breakpad project) class which register exception handler. It's necessary to implement this handler for each platform separately because each platform have different parameters in google_breakpad::ExceptionHandler() constructor. CrashHandler source code you can find also at end of this post.
Do almost all steps like on Linux integration. There is one exception, because you can't compile Breakpad tools using linux-like configure&make. You have to build these tools with XCode.
Compile google_breakpad/src/tools/mac/dump_syms/dump_syms.xcodeproj with XCode
Before I managed to successfully compile dump_syms in XCode, I have to update Architectures Debug/Release to 64-bit Intel and BaseSDK to "Latest Mac OS X". I also fix all issues displayed in the left part of XCode window.
Next step is change compilation type from Debug to Release. After a short searching I found a way in "Schema->Edit schema->Build configuration".
To be honest, I was not sure what I did, but it worked ;-). Maybe there is some easier way how to compile dump_syms in xcode, but I don't know how. This was my first contact with XCode ;-).
The application is compiled to path "/Users/User/Library/Developer/Xcode/DerivedData/dump_syms-bjvr/Build/Products/Release/dump_syms". Now copy dump_syms to safe location from where you will use it.
The most amazing thing I found about dump_syms is their platform independence. If you correctly extract symbol file on each platform and store it in one location, you can analyze any crashdump on one location. No matter what is source platform, you will analyze .dmp file by using **minidump_stackwalk ./crash.dmp ./symbols**.
How to include CrashHandler directly to your project
This is what I get when I follow all includes from **.h** and **.cpp** files starting with exception_handler.h for all platforms. With small modification you can include it to your project and your application will be fully breakpad-able ;-).
And this is the minimal implementation of your new CrashHandler. My ownd crash handler is much more sophisticate to perform reporting, sending crash dump etc. But for purposes of this article this is what you need (And also I don't want to share my whole know-how here ;-)))
I have a lot of virtual machines used for my everyday development. It's very frustrating the SVN update speed if you have several externals in your main SVN source.
Today when I wait for some compilation start searching if there is anything what could improve SVN speed. After searching a lot of articles about faster network, better server hdd,... I found article with mention how SVN client communicate with server (intensively ;-) ). But without any clue how to improve it.
So I start searching how SVN client communiacte from within VMWare machines to server. I noticed that VMWare default network settings is NAT: Used to share the host's IP address:
So I start trying other network methods and this is the result:
When I use "Custom: Specific virtual network" and choose "VMnet0 Bridged", my svn update is about ten times faster than on NAT settings!!. I also tried first option "Bridged:..." but this doesn't work for me.
Check "From" button in "Options" tab and enter shared address to "From" field in the mail header.
When mails will be forwarded back with error about "not enought permissions", simply remove exchange account from outlook and add it back again. This solution resolve my problem after 6 hours of debugging ;-(
This short post will show you how to resolve following error during Qt compilation on 64-bit windows:
This error is caused by bug in **QMAKE_HOST** variable used in WebCore.pro file. This variable is tested to determine destination platform (x86 or x64).
This variable contains x86 value also on 64-bit builds instead of x86_64 value. This value is tested on the following line in a WebCore.pro file:
If you want to fix this error, simply replace **QMAKE_HOST** by **QMAKE_TARGET** variable. Updated line should look like this:
After this update all required asm defines are correctly included and build of WebKit will be successful.
Update for this error
In newer versions of Qt there is already applied fix the error with QMAKE_HOST / QMAKE_TARGET, but also there is a new problem ;-(.
The Problem is in the following "if" definition:
When you compile your project for MSVC 2010, .asm file isn't included. It's necessary to add win32-msvc2010 to this definition. So updated WebCore.pro for Qt 4.8 will look like this:
Next problem solution
Next problem which I found during compilation is wrongly set QMAKE_TARGET.arg. For unspecified reason, when I compile 64bit library in 64bit system in 64bit VS command line, this variable has value x86 instead of x86_64.
The problem is in the qmake project.cpp file. QMAKE trying to determine 64/32 bit version based on the %PATH% configuration. Qmake search for VS-PATH\bin\amd64 of \bin\x86_amd64 string. Unfortunately there is a bug in concating searched string. This is how looks original project.cpp file at line 3177:
The problem is, that VCINSTALLDIR contains \ at the end of the string, and then we append \ again. So, result is:
Now, QMake correctly determine 32/64 bit compilation and then correctly include PaintHooks.asm and your Qt WebCore will be sucesfully compiled.