QDebug plante avec CuteTest

Bonjour,
J'utilise CuteTest dans mon projet qui est une surcouche du module de test unitaire Qt. Lorsque je veux appeler qDebug() dans le code du test ou bien dans mon code, ça plante. J'ai lu que qDebug() est lié à QApplication, mais comme cette partie là est gérée par la lib CuteTest je ne vois pas trop comment arranger les choses.

En gros le main de test appelle cette fonction de la lib :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int TestConsoleFrontend::main(int argc, char *argv[]) { QCoreApplication app(argc, argv);   if (TestRunner::execInnerProc()) { return 0; }   TestRunner runner; TestConsoleFrontend frontend(&runner);   // NOTE: Results are printed asynchronously (because the tests run in a child process due to limitations in QTest). runner.runAllTests();   return app.exec(); }

---

Je suppose que le plantage vient du fait que le code contenant mes QDebug est appelé au niveau de runAllTests() donc quand app.exec() n'a pas encore été appelé.

Est-ce qu'il y a un moyen d'utiliser QDebug() autrement sans qu'il repose sur QApplication ? std::cerr fonctionne normalement, j'aurais juste besoin de QDebug pour afficher facilement les objets Qt (listes etc) pendant mes tests.

Bonjour,

Je doute que ce soit le app->exec() qui pose problème. Avez-vous essayé de mettre un qIntallMsgHandler() pour voir ce si ça plante toujours avec ? La lib CuteTest en a peut-être installé un qui ferait planter ? À voir au débogage.

Bonne continuation,
Amnell.

Regarde si tu n'as pas le même problème que dans cette discussion avec le paramètre argc de ton constructeur (déclaré int au lieu de int&)

J'ai essayé de recompiler la lib avec int& mais ça ne change rien. De toute façon ça ne plante qu'avec un qDebug() dans le code. De plus l'appel au main de la lib se fait en une ligne, l'argument entier ne pourrait pas être modifié en dehors du corps de la fonction que j'ai copié au début.

J'ai recherché un appel à qIntallMsgHandler() dans le code de la lib sans succès, pas de QtMsgType non plus.

J'ai lancé mon test avec gdb, j'obtiens la pile suivante. C'est dans le code de CuteTest que ça plante, et à première vue je ne vois pas vraiment pourquoi, donc je pense que je vais laisser tomber et me passer de QDebug tant pis.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7baa7a0 in CuteTest::TestCase::addIncident (this=0x7fffffffd350, incident=...) at ../src/TestCase.cpp:110   (gdb) backtrace #0 0x00007ffff7baa7a0 in CuteTest::TestCase::addIncident (this=0x7fffffffd350, incident=...) at ../src/TestCase.cpp:110 #1 0x00007ffff7ba9d86 in CuteTest::QTestXmlParser::parseIncident (this=0x7fffffffd580, elem=..., testCase=0x7fffffffd350) at ../src/QTestXmlParser.cpp:156 #2 0x00007ffff7ba9409 in CuteTest::QTestXmlParser::parseTestCase (this=0x7fffffffd580, elem=...) at ../src/QTestXmlParser.cpp:96 #3 0x00007ffff7ba9039 in CuteTest::QTestXmlParser::parse (this=0x7fffffffd580, xml=..., srcFile=..., buildDir=...) at ../src/QTestXmlParser.cpp:70 #4 0x00007ffff7bba910 in CuteTest::TestRunner::onFoundEnvelopedXml (this=0x7fffffffdfc0, xml=..., fileName=..., buildDir=...) at ../src/TestRunner.cpp:140 #5 0x00007ffff7bc400a in CuteTest::TestRunner::qt_metacall (this=0x7fffffffdfc0, _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x7fffffffd770) at debug/moc_TestRunner.cpp:91 #6 0x00007ffff7864b27 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #7 0x00007ffff7bc4969 in CuteTest::XmlEnvelopeParser::foundEnvelopedXml (this=0x614968, _t1=..., _t2=..., _t3=...) at debug/moc_XmlEnvelopeParser.cpp:86 #8 0x00007ffff7bc3813 in CuteTest::XmlEnvelopeParser::parseContent (this=0x614968) at ../src/XmlEnvelopeParser.cpp:84 #9 0x00007ffff7bc348b in CuteTest::XmlEnvelopeParser::append (this=0x614968, data=...) at ../src/XmlEnvelopeParser.cpp:38 #10 0x00007ffff7bba7bd in CuteTest::TestRunner::onSubProcReadyReadStdout (this=0x7fffffffdfc0) at ../src/TestRunner.cpp:129 #11 0x00007ffff7bc3fb3 in CuteTest::TestRunner::qt_metacall (this=0x7fffffffdfc0, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7fffffffd960) at debug/moc_TestRunner.cpp:88 #12 0x00007ffff7864b27 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #13 0x00007ffff77ea41c in ?? () from /usr/lib/libQtCore.so.4 #14 0x00007ffff77eacb9 in QProcess::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #15 0x00007ffff7864b27 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #16 0x00007ffff78b0b1e in QSocketNotifier::activated(int) () from /usr/lib/libQtCore.so.4 #17 0x00007ffff7869653 in QSocketNotifier::event(QEvent*) () from /usr/lib/libQtCore.so.4 #18 0x00007ffff784ccdc in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #19 0x00007ffff787954a in ?? () from /usr/lib/libQtCore.so.4 #20 0x00007ffff4d87342 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #21 0x00007ffff4d8b2a8 in ?? () from /lib/libglib-2.0.so.0 #22 0x00007ffff4d8b45c in g_main_context_iteration () from /lib/libglib-2.0.so.0 #23 0x00007ffff7879193 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #24 0x00007ffff784ba02 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #25 0x00007ffff784bdec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #26 0x00007ffff784febb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #27 0x00007ffff7bab5ff in CuteTest::TestConsoleFrontend::main (argc=1, argv=0x7fffffffe118) at ../src/TestConsoleFrontend.cpp:64 #28 0x0000000000406744 in main (argc=1, argv=0x7fffffffe118) at ../../monprojet/test/test.cpp:30

---

Le contexte :

Code:

---

1 2 3 4 5 6

void TestCase::addIncident(const TestIncident& incident) { this->m_data->m_incidents.append(incident);   // Update incident count this->m_data->m_counts[incident.type()]++; ...

---

C'est la dernière ligne (5 ici) qui fait planter. Je ne vois pas bien le rapport que peut avoir QDebug, sans doute une histoire de threads ? (je n'y connais rien)

Bonjour,

Sur plusieurs tests, c'est toujours au même endroit que cela plante ? Ce que je proposais, en plus de rechercher une occurrence chez CuteTest, était d'utiliser qInstallMsgHandler() afin de choisir comment afficher les messages de qDebug()/qCritical()/etc... de façon à utiliser par exemple std::cerr et de voir si cela fonctionne mieux.

Bonne continuation,
Amnell.

Sur plusieurs tests ça plante toujours au même endroit oui, donc j'imagine qu'il s'agit d'une fragilité interne à CuteTest. Surtout que ça plante de la même façon avec le msghandler :

Code:

---

1 2 3 4 5 6 7 8 9 10

void msgHandler(QtMsgType, const char* msg) { std::cerr << msg << std::endl; }   int main(int argc, char *argv[]) { qInstallMsgHandler(msgHandler); return CuteTest::TestConsoleFrontend::main(argc, argv); }

---

Quand on regarde la pile il ne me semble pas que qDebug() soit appelé du tout. Donc ça plante avant ça, j'ai du mal à comprendre ce qui pourrait modifier le comportement de la lib, avant que le code différent soit exécuté (puisque sans qDebug() ça ne plante pas).

Les symptomes décrits font plutôt penser à un bug du genre heisenbug.

En ajoutant/enlevant un qDebug() et surtout ses arguments, ça décale potentiellement certaines autres variables en mémoire et donc change complètement la probabilité de déclencher le SIGSEGV, s'il s'agit par exemple d'une variable non initialisée.

Si c'est le cas, un outil comme valgrind peut aider à trouver l'erreur.

Je ne suis pas très au fait de ce genre de problème, mais ça ne me semble pas si aléatoire justement. Quel que soit l'endroit dans le code où j'appelle qDebug() ça plante, au même endroit avec la même pile d'appels de fonctions.

Sinon je viens de me rendre compte qu'en appelant qDebug avant l'appel au main de la lib, ça ne plante pas. donc le problème se situe bien dans la portion de code donnée au tout début (qui appelle tout le reste du programme... donc ça reste très vague).

Citation:

---

Envoyé par estofilo

Si c'est le cas, un outil comme valgrind peut aider à trouver l'erreur.

---

La conclusion logique. :)

Nouvel indice ^^ l'appel à qDebug() ne fait pas planter dans le corps de la fonction main de la lib (copiée au premier post), mais dans le corps des tests (qui sont des private slots, sur le modèle de QTest).
Le plantage a lieu après que toute la fonction main soit exécutée, donc pendant le app.exec(), vu que les fonctions de tests sont des slots j'imagine qu'elles sont gérées par la boucle d'évènements de l'application et c'est là que ça plante. Je ne connais pas assez bien le mécanisme interne, je n'ai aucune idée de ce qui pourrait poser problème dans ce contexte =/