Crash étrange d'un QTimer

Version imprimable

29/10/2012, 22h06
esteban

Crash étrange d'un QTimer

Bonjour à tous !

j'ai un crash très étrange avec un simple QTimer... Je suis sous Qt 4.8.3 sous Windows avec VC++ 2010 Express et le SDK 7.1 (je n'ai pas encore fait le test sous OSX).

J'ai un simple contrôleur qui possède un slot private nommé flush()
J'ai un QTimer instancié sur la pile dans les attributs de mon contrôleur.
Dans le constructeur de mon contrôleur je connecte QTimer::timeout() et this::flush().
Le timer est programmé avec un intervalle de 5s indéfiniment.
Le contrôleur possède aussi une méthode start() qui, entre autres lance le timer.

La fonction flush() effectue une simple sauvegarde des données d'un DAO...

Mon problème est le suivant :
Au bout d'une durée que je n'ai pas encore réussi à déterminer avec précision mais que je situerai entre 30mn et 1h l'application crash avec une erreur de lecture sur un pointeur (je n'ai plus le code exact de l'erreur en tête). Autant dire que le timer fonctionne très bien entre 300 et 600 fois avant de crasher.
Le débuggueur s'arrête à la dernière ligne de la fonction qt_static_metacall (la ligne qui contient seulement l'accolade fermante de la fonction). Je n'ai aucun autre information !! Ca plante assurément, à chaque lancement de l'application, au bout d'une plus ou moins longue période (je vais essayer de voir si cette période est constante ou non).

J'ai regardé les valeurs passées en paramètre de cette fonction du contrôleur et elles sont toutes initialisées. L'index de la méthode à exécuter est correct, il correspond bien à la méthode flush().

Est-ce que quelqu'un à déjà rencontré ce problème ? Faut-il que j'essaye avec une autre version de Qt ? du compilateur ?

Merci si vous pouvez m'aider parce que là je suis très embêté.
29/10/2012, 22h59
gbdivers

Bonjour

Déjà utilisé des timers qui tournent pendant longtemps sans problème. Le problème de vient probablement pas du timer, mais plutôt de son utilisation. Du code ?
30/10/2012, 08h09
esteban

Cela signifierait que le débugger se trompe quand il m'indique que le crash a eu lieu dans qt_static_metacall ?
C'est tout à fait envisageable qu'il y ait un bug dans ma fonction flush()... Sans doute même plus qu'un bug dans Qt ;-)

Je vérifie à nouveau. Et si quelqu'un à une autre idée du genre magique je suis preneur ! :D

En attendant voici mon code :

Controller.php

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
class MachinesController : public QObject
{    
    Q_OBJECT
public:
    explicit MachinesController(QObject *parent = 0);
    ~MachinesController();
public slots:
    void start();
    void flush();
private:
    QHash<QString, Machine>       machines_;
    QReadWriteLock                      machinesLock_;
    QTimer                                 flushTimer_;
    bool                                       changed_;
    MainFilter                          mainFilter_;
    bool                                    isFlushing_;

Controller.cpp

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
MachinesController::MachinesController(QObject *parent) :
    QObject(parent), changed_(false), isFlushing_(false)
{
    connect(&flushTimer_, SIGNAL(timeout()), this, SLOT(flush()));
    flushTimer_.setInterval(5000);
}
 
MachinesController::MachinesController(const MachinesController &) {}
 
MachinesController::~MachinesController()
{
    stop();
}
 
void MachinesController::start()
{
    flushTimer_.start();
}
 
void MachinesController::flush()
{
    if(isFlushing_)
        return;
 
    isFlushing_ = true;
    machinesLock_.lockForRead();
 
    if(changed_)
    {
        //Logger::getInstance().debug("Saving database");
 
        MachineDao dao;
        QHashIterator<QString, Machine> it(machines_);
        while(it.hasNext())
        {
            it.next();
 
            Machine m = it.value();
            if(!m.isLocalhost() && !m.isMainRouter())
                dao.persist(m);
        }
 
        changed_ = false;
    }
 
    machinesLock_.unlock();
    isFlushing_ = false;
}

31/10/2012, 15h09
esteban

Bonjour,

j'en remets une couche parce que le problème avait "disparu", en tout cas j'avais réussi à m'en débarasser... non en agissant spécifiquement dessus mais j'ai pas mal bougé le code et ca ne s'est pas reproduit.

En revanche, j'ai compilé mon appli en release, l'ai installée sur un autre ordinateur (sous XP) et patatra ! J'ai un autre timer qui plante. C'est parfaitement incompréhensible !

C'est exactement le même problème :
une instance d'un contrôleur, un QTimer instancié sur le tas celui-là avec this comme parent, le tout dans le contructeur.
Le connect est fait sur un public slot de this... Le crash se produit sur un else dans le slot... C'est chaud à débugger là (en plus c'est sur une autre machine et le bug ne se produit pas localement, ca sent le remote debugger...) !
Par contre c'est toujours la même erreur : impossible de lire une valeur en mémoire.

Toujours pas d'idée ??
31/10/2012, 15h21
gbdivers

Il faut se méfier des débug parfois, ils ne donnent pas toujours la position exacte où se trouve l'erreur

Sinon, ce genre d'erreur non reproductible vient souvent d'un problème de qualité du code... passe tout à l'analyse statique (cppcheck) et valgrind peut être
31/10/2012, 15h39
esteban

Ah tiens c'est bien ca cppcheck je croyais que je n'arriverais pas à trouver un analyseur sous Windows... merci !

De toutes façons j'ai bien conscience que le problème ne vient pas de QTimer mais de mon code... sauf pour que débusquer ce bug, faut y aller !
En plus avec Qt je ne trouve pas de moyen de faire du remote debug. :cry:
31/10/2012, 16h08
gbdivers

De plus, comme tu es en multi thread, n'hésite pas à utiliser l'outil DRD de valgrind (ou un équivalent, je suis pas sur qu'il soit sous win)

Merci pour les infos.
CppCheck ne m'a rien de trouvé de grave ouf !

En revanche moi je viens de trouver quelque chose :
Dans un des threads qui démarrent à partit de l'execution du timer j'en ai un qui fait une connexion sur une socket TCP.

Voici mon appel :
Code:

1 2 3 4 5 6 7 8 socket_ = new QTcpSocket(this); connect(socket_, SIGNAL(connected()), this, SLOT(onConnected())); connect(socket_, SIGNAL(stateChanged(QAbstractSocket::SocketState)), this, SLOT(onStateChanged(QAbstractSocket::SocketState))); url_ = urls_.at(rand() % (urls_.size()-1)); Logger::getInstance().debug(QString("Trying to connect to %1").arg(url_)); QTimer::singleShot(1000, this, SLOT(onContinue())); socket_->connectToHost(url_, 80);
et voilà le truc : si ma connexion se déroule bien et rapidement il y a de fortes chances que le QTimer que je connecte à onContinue tente de se connecter à rien car l'instance de this n'existera plus...
C'est con mais je suis sur que c'est ça !
Je nettoie tout ça et je vous redis.

31/10/2012, 16h48
esteban

Bon ben ça semble être ça !

Depuis que j'instancie mon timer sur le tas et que je le stoppe à la fin du process, dans tous les cas (connexion, erreur, etc...) ca ne plante plus.

Donc pour résumer : quand on a un QTimer qui crash il faut chercher à débuguer ce qui est déclenché, et s'armer de patience...

Merci de m'avoir aidé en tout cas.