Debugging Techniques

When configuring Qt for installation, it is possible to ensure that it is built to include debug symbols that can make it easier to track bugs in applications and libraries. However, on some platforms, building Qt in debug mode will cause applications to be larger than desirable.

Debugging in macOS and Xcode▲

When you run a Qt application, you can specify several command-line options that can help with debugging. These are recognized by QApplication.

At runtime, a Qt application recognizes many environment variables, some of which can be helpful for debugging:

Qt includes global C++ macros for writing out warning and debug text. The plain macros use a default logging category; the categorized logging macros allow you to specify the category. You can use them for the following purposes:

If you include the <QtDebug> header file, the qDebug() macro can also be used as an output stream. For example:

qDebug() << "Widget" << widget << "at position" << widget->pos();

The Qt implementation of these macros prints to the stderr output under Unix/X11 and macOS. With Windows, if it is a console application, the text is sent to console; otherwise, it is sent to the debugger.

By default, only the message is printed. You can include additional information by setting the QT_MESSAGE_PATTERN environment variable. For example:

QT_MESSAGE_PATTERN="[%{time process} %{type}] %{appname} %{category} %{function} - %{message}"

The format is documented in qSetMessagePattern(). You can also install your own message handler using qInstallMessageHandler().

If the QT_FATAL_WARNINGS environment variable is set, qWarning() exits after printing the warning message. This makes it easy to obtain a backtrace in the debugger.

qDebug(), qInfo(), and qWarning() are debugging tools. They can be compiled away by defining QT_NO_DEBUG_OUTPUT, QT_NO_INFO_OUTPUT, or QT_NO_WARNING_OUTPUT during compilation.

The debugging functions QObject::dumpObjectTree() and QObject::dumpObjectInfo() are often useful when an application looks or acts strangely. More useful if you use object names than not, but often useful even without names.

In QML, dumpItemTree() serves the same purpose.

You can implement the stream operator used by qDebug() to provide debugging support for your classes. The class that implements the stream is QDebug. Use QDebugStateSaver to temporarily save the formatting options of the stream. Use nospace() and QTextStream manipulators to further customize the formatting.

Here is an example for a class that represents a 2D coordinate.

QDebug operator<<(QDebug dbg, const Coordinate &c)
{
    QDebugStateSaver saver(dbg);
    dbg.nospace() << "(" << c.x() << ", " << c.y() << ")";

    return dbg;
}

Integration of custom types with Qt's meta-object system is covered in more depth in the Creating Custom Qt Types document.

The header file <QtGlobal> contains some debugging macros and #defines.

Three important macros are:

• Q_ASSERT(cond), where cond is a boolean expression, writes the warning "ASSERT: 'cond' in file xyz.cpp, line 234" and exits if cond is false.

• Q_ASSERT_X(cond, where, what), where cond is a boolean expression, where a location, and what a message, writes the warning: "ASSERT failure in where: 'what', file xyz.cpp, line 234" and exits if cond is false.

• Q_CHECK_PTR(ptr), where ptr is a pointer. Writes the warning "In file xyz.cpp, line 234: Out of memory" and exits if ptr is 0.

These macros are useful for detecting program errors, e.g. like this:

char *alloc(int size)
{
    Q_ASSERT(size > 0);
    char *ptr = new char[size];
    Q_CHECK_PTR(ptr);
    return ptr;
}

Q_ASSERT(), Q_ASSERT_X(), and Q_CHECK_PTR() expand to nothing if QT_NO_DEBUG is defined during compilation. For this reason, the arguments to these macro should not have any side-effects. Here is an incorrect usage of Q_CHECK_PTR():

char *alloc(int size)
{
    char *ptr;
    Q_CHECK_PTR(ptr = new char[size]);  // WRONG
    return ptr;
}

If this code is compiled with QT_NO_DEBUG defined, the code in the Q_CHECK_PTR() expression is not executed and alloc returns an uninitialized pointer.

The Qt library contains hundreds of internal checks that will print warning messages when a programming error is detected. We therefore recommend that you use a debug version of Qt when developing Qt-based software.

Logging and categorized logging are also possible in QML.

There is one bug that is so common that it deserves mention here: If you include the Q_OBJECT macro in a class declaration and run the meta-object compiler (moc), but forget to link the moc-generated object code into your executable, you will get very confusing error messages. Any link error complaining about a lack of vtbl, _vtbl, __vtbl or similar is likely to be a result of this problem.