Find a running timer in another thread

[ocgltd]

I have a fairly large multithreaded app. After the app shuts down I see the following error:

QObject::killTimer: Timers cannot be stopped from another thread
QObject::~QObject: Timers cannot be stopped from another thread

So it would seem that I dynamically create a QTimer that I'm not deleting. I've tried to find it but no luck. I was hoping to set a breakpoint in the killTimer method in QObject, but i don't have the source installed (installed from binary installer on Qt site).

Can someone recommend a way to figure out where the running timer is?

[Christian Ehrlicher]

@ocgltd said in Find a running timer in another thread:

Can someone recommend a way to figure out where the running timer is?

Use QT_FATAL_WARNINGS as described in the Qt debugging docs and take a look at the backtrace to see which timer gets destroyed.

[ocgltd]

@Christian-Ehrlicher That looks like a good approach. I tried it and discovered that the Qt bluetooth library calls qCWarning just to notify me of information that should probably be a qDebug:

qCWarning(QT_BT_BLUEZ) << "No uuids found for" << deviceAddress.toString();

I tried to comment out the line above (in file qbluetoothservicediscoveryagent_bluez.cpp) but no effect. Steering a bit off topic, how do I recompile the Qt bluetooth library? (Changing the file above does not force it to recompile when I build my project)

Or is there a way to disable any warnings with the QT_BT_BLUEZ parameter passed to qCWarning?

[JonB]

@ocgltd
Your original question is about tracking down a timer. Is this related to it, or just a quite separate question, I am unsure?

If you are now asking about disabling these qCWarning(QT_BT_BLUEZ) messages from appearing --- is that what you want? --- have you read QLoggingCategory Class?

[ocgltd]

@JonB This is part of the same question.

I enabled QT_FATAL_WARNINGS as you suggested, hoping that on program shutdown the abort would allow me to traceback the QTimer issue.

However, my program uses Qt's Bluetooth library which calls qCWarning (just to notify me of operational information) - which causes the program to abort. So I never get to the point of shutdown so that I can trace the QTimer error.

I figured I would just comment out the line of code in the Qt Bluetooth library but it's having no effect, I assume it must be compiled seperatly.

[JoeCFD]

@ocgltd
from here:
https://doc.qt.io/qt-5.15/qtimer.html#details
In multithreaded applications, you can use QTimer in any thread that has an event loop. To start an event loop from a non-GUI thread, use QThread::exec(). Qt uses the timer's thread affinity to determine which thread will emit the timeout() signal. Because of this, you must start and stop the timer in its thread; it is not possible to start a timer from another thread.

===============================================================
when the timer is started, save the thread ID or thread pointer and make sure the same thread is applied to stop the timer.

if ( QThread::currentThread() == m_savedThread ) {
       stop the timer
}

[JonB]

@ocgltd
Now I understand. It was @Christian-Ehrlicher who suggested QT_FATAL_WARNINGS. He may have a better suggestion for your situation. Did you try disabling the QT_BT_BLUEZ category to see if that allows your code to proceed over this warning message?

[JonB]

@JoeCFD The OP is aware they have a QTimer in another thread, their question is how can they track down where?

[ocgltd]

@JonB
For anyone else trying to figure this out, the correct syntax to disable the qCWarning from the bluetooth class is:

QLoggingCategory::setFilterRules("qt.bluetooth*=false");

Now for the interesting part. The class which leaves a timer running seems to be BluetoothManagement (file bluetoothmanagement_p.h). Which is created by class Holder (file bluetoothmanagement.cpp)

I suppose it's good that it's not my code (I think)...so should I file a bug report? Or is there something I need to do to ensure proper bluetooth class shutdown? I don't create either of the above classes directly. The bluetooth documentation is a bit weak, so I'm open to consider that I'm doing something wrong.

[ocgltd]

This post is deleted!

[JonB]

@ocgltd said in Find a running timer in another thread:

I have a fairly large multithreaded app

I would first suspect your own code. You will need a minimal reproducer to report it as a bug anyway, so I suggest you find what what is necessary for the message to appear.