Qt Commercial Support Weekly #22 - Debugging with Qt tips

Many of you out there will be debugging their applications and sometimes into Qt as well on a fairly regular basis on the different platforms. For the most part you will be using Qt Creator which will simplify things a lot for you. However if you are using a slightly different setup, such as Visual Studio on Windows or the binary packages on Mac OS X then there will be some things you may not be aware of that could prove useful to you.

On Windows, if you are using Visual Studio then this will give you a lot of things working out of the box, however you may find that the Qt types and classes are not showing the information that you want inside the debugger, for example the QString is not showing the contents of the QString when you are expanding the variable inside the autos/locals/watch window. Luckily there is an easy way to get this and other Qt based types and classes to be automatically showing the relevant information when using Visual Studio. If you install the Qt Visual Studio Add-In plugin then in addition to providing you with a means to create Qt projects with ease it will also install extra debugger settings so that you can see the contents of a QString straight away.

If you are using Qt Creator on Windows then this will work for you even if you are using Visual Studio to build Qt and your projects as with the debugging tools installed Qt Creator can also work with the Visual Studio debugger (cdb) so you don't have to rely on MinGW to be able to use Qt Creator for your applications either.

On Mac, if you want to be able to debug into the Qt code and you are using the binary packages then you will need to set up gdb to be able to find the source. After you have installed the normal binary package followed by the one with the debug symbols then you will need to download the source package and unarchive it somewhere. You don't need to build this source package as it is just enough that the source exists somewhere. Once you have done this then when starting gdb you just need to run the following commands:

directory /path/to/qt/src/corelib

directory /path/to/qt/src/gui

directory /path/to/qt/src/sql

etc

Just add an extra directory line for each module you need to be able to debug into and then when you debug an application using the binary package then you will be able to debug into Qt if need be.

As someone who has worked in Qt support for over 11 years now (time certainly flies when you are having fun) then I have picked up some useful approaches along the way when it comes to trying to pinpoint problems inside Qt. These may seem obvious to you already but hopefully some of you will get something useful from this.

What I find a lot of the time is that sometimes putting in debug statements is quite useful before doing any actual debugging, Qt is good in this respect as it already has a fair number of different debug statements in there which can be turned on. Two notable mentions in this respect are the debug messages in qmake which can be turned on by passing -d as an argument to qmake when running. You can pass -d up to four times to get more and more levels of debugging information. The other notable mention is in the network module, which has a commented out define in most of the files, by uncommenting out this define you can get a lot of information about what is happening inside the network module. This is useful when trying to pinpoint network problems and is also useful to support if you hit such a problem to see what is going on there. Also, any warning messages coming from Qt are usually there for a good reason so it makes sense to pay attention to these if you have any problems.

For drawing errors then sometimes having the current output drawn to a pixmap and then saved is handy if you do it in stages so you can see what each part of the painting looks like in case you are not sure what is being missed. This is especially useful with styles as there is a lot of drawing code going on there and breaking down into parts sometimes clarifies what is going wrong. And while I am on the subject of styles, if you see a problem that is happening with a style then you can try the different styles to see if it is actually style specific. You can run your application with the -style stylename option to see it run in different styles. The same can be done for the different painting systems, for most cases you can switch from raster (which is usually the default) to opengl to see if the problem is in the raster paint engine. To do this you can use -graphicssystem opengl.

As always with development and especially if you are debugging inside Qt then it can just come down to experience, knowledge and in more cases than you would think luck too. Sometimes we spend a considerable amount of time debugging a bug in Qt to try and find a solution for the bugs reported to us via the customer portal and while we succeed a lot of the time there are some times it doesn't work out for us unfortunately. But in those cases we do report the bug further to the Qt Commercial R&D team who will look into the bug at a later point.

So I hope you got something from this and until next time, happy coding :)