Techniques de débogage

Nous présentons ici quelques conseils utiles pour le débogage de logiciels basés sur Qt.

Configurer Qt pour le débogage
Débogage sur Mac OS X avec Xcode	Avec framework	Taille des symboles de débogage
Débogage avec et sans framework	Sans framework

Configurer Qt pour le débogage

Lorsque vous configurez Qt pour l'installation, il est possible de demander à ce que les symboles de débogage soient inclus à la compilation, ce qui peut faciliter la recherche de bogues dans les applications et les bibliothèques. Cependant, sur certaines plateformes, compiler Qt en mode débogage peut faire grossir les applications au-delà de la taille souhaitée.

Débogage sur Mac OS X avec Xcode

Débogage avec et sans framework

Les informations de base sur les bibliothèques et frameworks de débogage se trouvent sur developer.apple.com le portail des développeurs Apple dans une note sur les techniques d'Apple TN2124.

Lorsque vous compilez Qt, les frameworks sont compilés par défaut et, dans le framework, vous trouverez à la fois une version release et une version debug (par exemple, QtCore et QtCore_debug). Si vous passez l'option -no-framework lorsque vous compilez Qt, deux dylib sont créées pour chaque bibliothèque Qt (par exemple, libQtCore.4.dylib et libQtCore_debug.4.dylib).

Le comportement au moment de l'édition des liens dépend de l'usage ou non des frameworks. Nous ne voyons pas de raison majeure de recommander l'un ou l'autre.

Avec framework

Étant donné que les bibliothèques release et debug sont dans le framework, l'application est simplement liée avec le framework. Lorsque vous exécutez dans le débogueur, vous aurez la version debug ou release, suivant que vous aurez défini DYLD_IMAGE_SUFFIX ou pas. Si vous ne le définissez pas, vous aurez la version release par défaut (c'est-à-dire non _debug). Si vous définissez DYLD_IMAGE_SUFFIX=_debug, vous aurez la version debug.

Sans framework

Quand vous demandez à qmake de générer un Makefile avec la configuraion debug, il va faire un lien avec les versions _debug des bibliothèques et générer des symboles de débogage pour l'application. L'exécution de ce programme dans GDB fonctionnera comme sur les autres plateformes et vous pourrez tracer les appels à l'intérieur de Qt.

Taille des symboles de débogage

La place prise par les symboles de débogage générés par GCC peut être excessivement grande. Cependant, à partir de la version 2.3 de Xcode, il est possible d'utiliser les symboles Dwarf (nains), qui prennent nettement moins de place. Pour activer cette option à la configuration de Qt, passez l'option -dwarf-2 au script de configuration.

Cette option n'est pas activée par défaut, car les versions précédentes de Xcode ne fonctionnent pas avec l'option de compilation utilisée pour l'implémenter. Mac OS X 10.5 utilisera les symboles dwarf-2 par défaut.

Les symboles dwarf-2 contiennent des références au code source, la taille de l'application debug finale devrait donc pouvoir être comparée plus favorablement à celle d'une version release.

Options de ligne de commande reconnues par Qt

Lorsque vous exécutez une application Qt, vous pouvez spécifier plusieurs options de ligne de commande pouvant aider au débogage. Elles sont reconnues par QApplication.

Option	Description
-nograb	L'application ne doit jamais prendre en compte la souris ou le clavier. Cette option est activée par défaut si le programme est lancé dans le débogueur gdb sous Linux.
-dograb	Ignorer tout -nograb explicite ou implicite. -dograb a la priorité sur -nograb, même quand -nograb est situé après sur la ligne de commande.
-sync	Exécute l'application en mode X synchrone. Le mode synchrone force le serveur X à traiter chaque requête des clients X immédiatement et à ne pas utiliser de tampon d'optimisation. Cela rend le programme plus facile à déboguer et souvent plus lent. L'option -sync n'est valide que pour la version X11 de Qt.

Messages d'avertissement et de débogage

Qt inclut quatre fonctions globales pour l'écriture de texte d'avertissement et de débogage. Elles correspondent aux usages suivants :

• qDebug() est utilisée pour les sorties de débogage personnalisées ;
• qWarning() est utilisée pour des avertissements et des erreurs récupérables dans l'application ;
• qCritical() est utilisée pour des erreurs critiques et les erreurs systèmes ;
• qFatal() est utilisée pour tracer des erreurs fatales juste avant l'arrêt de l'application.

Si vous incluez le fichier d'en-tête <QtDebug>, la fonction qDebug() peut aussi être utilisée comme flux de sortie. Par exemple :

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

L'implémentation de ces fonctions envoie le texte vers la sortie stderr sous Unix/X11 et Mac OS X. Sous Windows, s'il s'agit d'une application console, le texte est envoyé à la console ; sinon, il est envoyé au débogueur. Vous pouvez réimplémenter ces fonctions en installant un gestionnaire de messages avec qInstallMsgHandler().

Si la variable d'environnement QT_FATAL_WARNINGS est définie, qWarning() termine le programme après l'impression du message d'erreur. Cela permet de retrouver facilement l'origine de la trace dans le débogueur.

qDebug() et qWarning() sont des outils de débogage. Elles peuvent être éliminées de l'exécutable en définissant QT_NO_DEBUG_OUTPUT et QT_NO_WARNING_OUTPUT à la compilation.

Les fonctions de débogage QObject::dumpObjectTree() et QObject::dumpObjectInfo() sont souvent utiles lorsque les applications se comportent étrangement. Elles sont plus utiles si vous utilisez les noms d'objet mais elles peuvent aussi être utilisées sans ces derniers.

Vous pouvez implémenter l'opérateur de flux utilisé par qDebug() pour fournir un meilleur support du débogage par vos classes. La classe implémentant le flux est

QDebug

. Les fonctions que vous avez besoin de connaître dans QDebug sont space() et nospace(). Elles renvoient toutes les deux un flux ; la différence est dans l'insertion ou non d'un espace entre les éléments. Voici l'exemple d'une classe représentant des coordonnées 2D.

 QDebug operator<<(QDebug dbg, const Coordinate &c)
 {
     dbg.nospace() << "(" << c.x() << ", " << c.y() << ")";
 
     return dbg.space();
 }

L'intégration de vos propres types dans le système de méta-objets de Qt est décrit en profondeur dans le document Créer des types Qt personnalisés.

Macros de débogage

Le fichier d'en-tête <QtGlobal> contient des macros de débogage et des #define.

Trois macros importantes sont :

• Q_ASSERT(cond), où cond est une expression booléenne, écrit l'avertissement « ASSERT: ‹cond› in file xyz.cpp, line 234 » et termine le programme si cond est false ;
• Q_ASSERT_X(cond, where, what), où cond est une expression booléenne, where un lieu et what un message, écrit l'avertissement : « ASSERT failure in where: ‹what›, file xyz.cpp, line 234 » et termine le programme si cond est false ;
• Q_CHECK_PTR(ptr), où ptr est un pointeur, écrit l'avertissement « In file xyz.cpp, line 234: Out of memory » et termine le programme si ptr est 0.

Ces macros sont utiles pour la détection d'erreurs dans les programmes, par exemple comme ceci :

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

Q_ASSERT(), Q_ASSERT_X() et Q_CHECK_PTR() ne génèrent pas de code si QT_NO_DEBUG est défini pendant la compilation. Pour cette raison, les arguments de ces macros ne doivent pas avoir d'effet de bord. Voici un usage incorrect de Q_CHECK_PTR() :

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

Si ce code est compilé avec QT_NO_DEBUG défini, le code dans l'expression Q_CHECK_PTR() n'est pas exécuté et alloc renvoie un pointeur non initialisé.

La bibliothèque Qt contient des centaines de contrôles internes qui vont produire des messages d'avertissement quand une erreur de programmation est détectée. Nous recommandons donc d'utiliser une version de débogage de Qt pendant le développement de logiciels basés sur Qt.

Bogues courants

Il existe un bogue tellement courant qu'il mérite d'être mentionné ici : si vous incluez la macro Q_OBJECT dans une déclaration de classe et exécutez le compilateur de méta-objets (moc) mais oubliez de lier le code objet généré par le moc dans votre exécutable, vous obtiendrez des messages d'erreur difficiles à interpréter. Les erreurs de lien signalant l'absence de vtbl, _vtbl, __vtbl ou des choses similaires sont probablement une manifestation de ce problème.

Remerciements

Merci à Ilya Diallo pour la traduction ainsi qu'à Jonathan Courtois, Thibaut Cuvelier et Maxime Gault pour la relecture !