timers cannot be stopped from a different thread
-
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
-
Run your app with a debugger and a set env var QT_FATAL_WARNINGS
-
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
@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 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.
@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.
-
@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.
This post is deleted!
