QTimer stop responding after some time

Svirac

Hi guys,

I am counting on your help, as usually… this time I am stuck :/

It seems that I am having issues with QTimer.
In general my application is consisted of several threads, threading is done with moveToThread() (I followed recommendations etc.).

Inside each thread, I am using QTimer to generate ticks. In general, once when thread is started, I am allocating Timer, define connections (timeout to listen) and then start the timer.

I double-checked threadIDs in each step, and it seems that threads work as expected.

Here is the problem:
Test is done with 2 threads (there is also main/gui thread).
After few minutes, for some one of timers stops generating timeouts (actually, appropriate slot is not called anymore).
Sometimes after 10 minutes timer become “alive” again and start to work as expected.

I did some experimenting, and instead QTimer I am generating ticks on following way:
timer_tick_id = startTimer(5);

and adding handler:
void Comm1Controller::timerEvent(QTimerEvent* event) {
if (event->timerId() == timer_tick_id) {
..
}

For same timings this solution works “better”, it worked around 30 minutes and after that one of timers stopped to respond.

I am working on Win7, qt 4.6.2.

Please give me advices/thoughts…
Eventually I will drop from 1,2 ms to 5 and 10 ms loops, but I need to understand the problem, to make sure that this will not in the future.

I got an impression that QTimer queue gets overrun…
Is there a way to force Qt to give priority to QTimers or something like that?

Thanks in advance for any help…

CP71

@Svirac
Hi,
have you got QThread's sleep or QMutex or other kind of thread synchronization in your threads?

JonB

@Svirac
First please do answer @CP71's question, as any kind of thread block issue would always be a likely explanation.

However, if not: in thread https://forum.qt.io/topic/100981/qtimer-seems-to-just-stop we are currently discussing someone reporting the same sort of behaviour. It seems unlikely they are the same, you are using different Qts/platforms, and that timeout stop seems to have a connection to 71 minutes(!), but you might like to read through (the current suggestion is that a timer somehow "wraps round" a counter since very first started) and keep an eye on it, just in case they are related or it gives you ideas....

Svirac

Hi guys, spry for a delay, I was simplifying my code so that I can paste it here.
No, mutex or sleep are not used

class AppController : public QWidget
{
    Q_OBJECT
public:
    AppController (QWidget* parent=0);
    virtual ~AppController();

    QThread*            comm1Thread;
    Comm1Controller*    comm1controller;

    QThread*            comm2Thread;
    Comm2Controller*    comm2controller;
};

class AppController;

class Comm1Controller : public QObject
{
Q_OBJECT
public:
    Comm1Controller(AppController*  appcontroller, QObject* parent = 0);
    virtual ~Comm1Controller();

    QTimer* tick;
    int temp;

public slots:
    void slot_listen();
    void slot_start ();
};

class AppController;

class Comm2Controller : public QObject
{
Q_OBJECT
public:
    Comm2Controller(AppController*  appcontroller, QObject* parent = 0);
    virtual ~Comm2Controller();

    QTimer* tick;
    int temp;

public slots:
    void slot_listen();
    void slot_start ();
 };

AppController::AppController (QWidget* parent): QWidget(parent) {

    // Set main windows size and position
    setFixedSize  (200,40); move          (800,0);
    
    // Comm 1
    comm1Thread =  new QThread (this);
    comm1controller = new Comm1Controller    (this, NULL);
    comm1controller->moveToThread(comm1Thread);

    connect(comm1Thread,  SIGNAL(finished ()),    comm1controller, SLOT  (deleteLater()));
    connect(comm1Thread,  SIGNAL(started ()),     comm1controller, SLOT  (slot_start()));

    comm1Thread->start();

    // Comm 2
    comm2Thread =  new QThread (this);
    comm2controller = new Comm2Controller    (this, NULL);
    comm2controller->moveToThread(comm2Thread);

    connect(comm2Thread,  SIGNAL(finished ()),    comm2controller, SLOT  (deleteLater()));
    connect(comm2Thread,  SIGNAL(started ()),     comm2controller, SLOT  (slot_start()));

    comm2Thread->start();
}

AppController::~AppController() { }

#include "comm1controller.h"
#include "../appcontroller/appcontroller.h"

Comm1Controller::Comm1Controller(AppController*  appcontroller, QObject *parent) : QObject()
{
     temp = 0;
     tick = new QTimer (this);
}
Comm1Controller::~Comm1Controller() { }


void Comm1Controller::slot_start ()
{
    connect(tick,    SIGNAL(timeout()) ,this    , SLOT(slot_listen()));
    tick->start (1);
}

void Comm1Controller::slot_listen()
{ 
    temp++;

    if (temp>100)
    {
        temp = 0;
        qDebug() << "comm1; slot_listen()," << "tick threadID:" << tick->thread()->currentThreadId();
    }
}

#include "comm2controller.h"
#include "../appcontroller/appcontroller.h"

Comm2Controller::Comm2Controller(AppController*  appcontroller, QObject *parent) : QObject()
{
    temp = 0;
    tick = new QTimer (this);
}
Comm2Controller::~Comm2Controller() { }

void Comm2Controller::slot_start ()
{
    connect(tick,    SIGNAL(timeout()) ,this    , SLOT(slot_listen()));
    tick->start (1);
}

void Comm2Controller::slot_listen()
{
    temp++;

    if (temp>100)
    {
        temp = 0;
        qDebug() << "comm2; slot_listen()," << "tick threadID:" << tick->thread()->currentThreadId();
    }
}

/edited by moderator - added proper code tags

Svirac

@JonB
At the moment I have a feeling that that for some reason, thread event loop stop been processing

CP71

@Svirac
try to move creation of timer in slot_start() ( tick = new QTimer (this); )
I normally create members in start slot

https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/

Svirac

@CP71
I tried that, but it has same effect :/

CP71

@Svirac
I seem to see a 1ms of timeout, isn't It too frequent?

Svirac

@CP71
Yes it is, agree.

Never the less I want to understand what is happening... I don't want to get surprised latter in the project, if same effect occurs with 5 ms timeouts.

Also question: what is happening if called slot doesn't manage to preform task (function) within e.g. 1 ms? I am assuming that QTimer timeouts are queued internally... is there some overflow?
Sorry for my language, I am not sure how to express myself properly :/

Thanks for helping me out , I really appreciate it... I am really desperate at this point :)

CP71

@Svirac
Don't worry! My English is not good :(
I'm interested to understand me too, you never know for future ;)

JonB

@Svirac

Also question: what is happening if called slot doesn't manage to preform task (function) within e.g. 1 ms? I am assuming that QTimer timeouts are queued internally... is there some overflow?

Depends whether your slot does or does not allow the event loop to run. Regardless I don't think they'll be queued.

Svirac

@JonB
I am thinking to generate some slower "guard" timer in separate thread.

To each thread fast timers I will add counter, locked with mutex. Guard timer will check counter and reset it each time. If counter is 0, it means that fast thread didn't accumulate it.... then guard timer will reset fast timer. Of course, over appropriate slot. My understanding is that its enough so simply start timer (it stops and reset).

Does it make sense?

Svirac

@JonB
For a last 1.5 hours I am running application with 5ms and 20ms timeouts and everything works fine....
with 1ms and 2 ms one of timers stops responding (one always remains active).

EDIT: just as I wrote this, after 1.5 hours one of faster timers (5ms) stop responding :(

CP71

@Svirac
I can say in our projects we have timers, some always active, some stopped in timeout slot and restart whet timeout slot is ended.
Our softwares run for a day or more, and so far we haven’t problems with QTimer.
Some problems with QElapsedTimer and sleep of thread, but not with QTimer, but happen in a particular condition and now we have learned to manage them, see https://forum.qt.io/topic/99973/qthread-msleep-doesn-t-work-when-system-time-is-changed

We have found a particular issue, but I didn't report because I want to check our code before to do this, we found that QTimer seems to stop run when a QMessageBox is shown, but is not always true this condition, so we must investigate why? Sometimes seems QMessageBox stops the even loop but I don’t know why, But at the moment for us is not a big problem and we can manage this condition.

SGaist

@CP71

Are you calling exec ? If so, it will spin it's own event loop which will handle the events while running. Use open in place so the main loop will be used.

CP71

@SGaist
thank you very much for your suggestion.
As soon as possible I’ll check and give you a confirm if I have used an open (in the hope I won’t forget to give you a confirm ;) ).
For the moment, thanks.
CP71

CP71

Hi @SGaist ,
better late than never ;).
Anyway sorry for late.
I don’t call exec to open my QmessageBox, I used a static method QMessageBox::warning( this , …) but I don’t know if it calls exec method.
This, in option, is QMainWindow where timer is run, timeout signals isn’t fired, or so it seems.
When QMessageBox is closed QTimer run again.

JonB

@CP71
3 months later :)

OK, your QMessageBox::warning() is an application-modal dialog and is behaving as though you had called the exec() which @SGaist mentioned.

And that is going to block the loop your timer runs under. You will need to rewrite your code to use the QMessageBox::open() call @SGaist referred you to.

For discussion see e.g. https://stackoverflow.com/questions/14676085/qmessagebox-halts-qtimer .

If this is an issue for you --- you always want some timer event firing in the background, but you have many modal dialogs to show and don't want to rewrite callers --- you might have to rethink your usage of QTimer.

JKSH

@Svirac said in QTimer stop responding after some time:

I am working on Win7, qt 4.6.2.

...

Eventually I will drop from 1,2 ms to 5 and 10 ms loops

Have you checked if your slots are actually getting called at the millisecond intervals that you specified? If I remember correctly, Qt 4 did not support precise timers on Windows -- timers were only accurate to 16 ms.

Also, may I ask why you're using Qt 4.6? Try to upgrade to Qt 4.8.7 at least. But since this is sounds like a new project, I really really recommend Qt 5.12.4 (long-term support version) or Qt 5.13.0 (latest version)

CP71

@JonB
Yeah, it is really long time :D
Thanks for your answer, no problem to use QmessageBox::open(), but the important thing is knowing why, and now thank to you and @Sgaist I know.
Thank you very much

Planned maintenance has been done but it did not solve the problem. So work will continue on this and a new time for trying updates will be announced asap.

QTimer stop responding after some time