timers cannot be stopped from a different thread

HJPE

My application uses a Qt GUI loaded at runtime from a dynamic library. When loading, I do the following:

Create a dedicated thread for Qt. The points 2) -5) all happen within this thread!!!
Allocate the QApplication object
Call QQmlComponent::create
Call QApplication::exit
Delete the QApplication object
Stop the Qt thread
Shut down my application. The last log output I see then is: QObject::~QObject: Timers cannot be stopped from another thread.

That is not nice, but what is really bothering me, is that some shutdown code of a dll I am using is not executed anymore. This is not happening if I do not load the library containing the Qt code. I would assume, that after point 6), there is no Qt object anymore, so why do I see this message?
As I said, I have been very careful to do everything in the qtmain (not application main) thread. How can I find out, what is causing this?

One thing: when using QQmlComponent, I am also using QQmlEngine::setObjectOwnership with QQmlEngine::CppOwnership, but removing this does not change the situation. This function is not documented sufficiently, I only use it because of the sample code I based my code on.

Many thanks

JoeCFD

You run Qt in another process, not in another thread.

Christian Ehrlicher

Run your app with a debugger and a set env var QT_FATAL_WARNINGS

JKSH

@HJPE said in timers cannot be stopped from a different thread:

I would assume, that after point 6), there is no Qt object anymore, so why do I see this message?

Unfortunately, there exists a global static QObject that you cannot delete. This is a known issue when you initialize Qt in a secondary thread: https://lists.qt-project.org/pipermail/development/2021-May/041517.html

You can safely ignore the Timer message.

HJPE

@JKSH I skipped two points in my list:
Before point 1), I load the dll which implicitly depends on Qt. The loading executable has no such dependency.
Before point 7), I unload this dll. So, all Qt related stuff should be unloaded as well. I would expect the warning to be issued at this occasion, not when the main process stops, which can be hours later.

I still have to make 100% sure though, that the dll is really, really unloaded. I will give more feedback when done so.

SpringRoach

This post is deleted!