Global static QPixmapCache in Qt internals
-
@J-Hilk said in QApplication in std::thread:
@JKSH this actually crashes for me on btn.show()
That's expected. MacOS does not support plugging into the event loop from a thread different from
main(). Should work on linux and windows, though.@kshegunov Apple does a lot of funky stuff, in that regard, let me fire up my vm
-
@JKSH said in QApplication in std::thread:
Ah, right... I thought the Debug build would suffice. Don't have a dev build right now.
Not once in a universe lifetime.
@JKSH said in QApplication in std::thread:
Might be Windows-specific.
Possibly. Unfortunately I don't have windows on hand (or rather I'm too lazy now to boot into it). Maybe, I'll check it later.
@kshegunov said in QApplication in std::thread:
Not once in a universe lifetime.
Duly noted :-D
But before we get too sidetracked: @Suthiro's main issue isn't the message about timers. Rather, it's the crash which I believe is caused by
delete m_qPlotsControl;(see https://stackoverflow.com/questions/67257329/weird-qpushbutton-bug ).I believe it is fixable with
m_qPlotsControl->deleteLater();... but that needs to be done before QApplication::exec() returns, because QDeferredDeleteEvent won't be processed without an event loop. -
@kshegunov said in QApplication in std::thread:
Not once in a universe lifetime.
Duly noted :-D
But before we get too sidetracked: @Suthiro's main issue isn't the message about timers. Rather, it's the crash which I believe is caused by
delete m_qPlotsControl;(see https://stackoverflow.com/questions/67257329/weird-qpushbutton-bug ).I believe it is fixable with
m_qPlotsControl->deleteLater();... but that needs to be done before QApplication::exec() returns, because QDeferredDeleteEvent won't be processed without an event loop.@JKSH Ok I can reproduce it as well, (on the VM) Qt 15.3 & MSVC2019
-
@kshegunov said in QApplication in std::thread:
Not once in a universe lifetime.
Duly noted :-D
But before we get too sidetracked: @Suthiro's main issue isn't the message about timers. Rather, it's the crash which I believe is caused by
delete m_qPlotsControl;(see https://stackoverflow.com/questions/67257329/weird-qpushbutton-bug ).I believe it is fixable with
m_qPlotsControl->deleteLater();... but that needs to be done before QApplication::exec() returns, because QDeferredDeleteEvent won't be processed without an event loop.@JKSH said in QApplication in std::thread:
I believe it is fixable with m_qPlotsControl->deleteLater();... but that needs to be done before QApplication::exec() returns, because QDeferredDeleteEvent won't be processed without an event loop.
I still don't understand this. For what reason should that be the case, and why would this generate a crash? I'm pretty sure deferred deletes are processed after the event loop has exited (see for example the
QThread::finished->QObject::deleteLater), but even if that weren't the case theQPushButton's destructor is going to be run before the thread actually finishes and before the application object's destructor's run (there's no difference betweenmain()and any other function from c++'s point of view). -
[Forked from https://forum.qt.io/topic/126128/qapplication-in-std-thread -- Sorry, I messed up the order of posts when I did the fork; this top post should be further down]
@kshegunov said in QApplication in std::thread:
why would this generate a crash?
Since the widget creates a timer in the background, then it's probably receiving background events/signals.
deletecould cause the event/signal handler to act on a dangling pointer -- that's how it could generate a crash. And that's whydeleteLater()can fix the crash. (Alternatively, we could change from a heap-allocated widget to a stack-allocated widget)I'm pretty sure deferred deletes are processed after the event loop has exited (see for example the
QThread::finished->QObject::deleteLater)The code below prints "Bye" but not "Widget destroyed", proving that the Widget's destructor is not run:
// widget.h #include <QWidget> class Widget : public QWidget { Q_OBJECT public: Widget(QWidget *parent = nullptr) : QWidget(parent) {} ~Widget(){ qDebug("Widget destroyed"); } }; // main.cpp #include "widget.h" #include <QApplication> #include <chrono> #include <thread> using namespace std::chrono_literals; int main(int argc, char *argv[]) { std::thread thr([&] { QApplication a(argc, argv); auto w = new Widget; w->show(); a.exec(); // delete w; // This WILL run the Widget's destructor w->deleteLater(); // This WON'T run the Widget's destructor }); std::this_thread::sleep_for(5000ms); QMetaObject::invokeMethod(qApp, &QApplication::quit); thr.join(); std::this_thread::sleep_for(5000ms); qDebug("Bye"); }Anyway, I was trying to say that @Suthiro can't simply replace
delete m_qPlotsControl;withm_qPlotsControl->deleteLater();in-place at https://stackoverflow.com/questions/67257329/weird-qpushbutton-bug . Some re-shuffling is required.@JKSH said in QApplication in std::thread:
The code below prints "Bye" but not "Widget destroyed", proving that the Widget's destructor is not run:
I meant connecting to the
aboutToQuitsignal, but anyhow it's not that important.Since the widget creates a timer in the background, then it's probably receiving background events/signals. delete could cause the event/signal handler to act on a dangling pointer -- that's how it could generate a crash.
I think this shouldn't happen, but can't investigate it currently.
Anyway, I was trying to say that @Suthiro can't simply replace delete m_qPlotsControl; with m_qPlotsControl->deleteLater(); in-place at https://stackoverflow.com/questions/67257329/weird-qpushbutton-bug . Some re-shuffling is required.
I suppose, but that timer message should go away, otherwise the code can break at any moment (this applies to your code too - the one you mentioned where you get the warning).
-
I reproduced this on Windows and the message about timers comes from a destructor of a static QPixmapCache object that happens on the main() thread. That's not something the user's code does. It's in Qt's internals.
Right, so remember the rule that no QObject should outlive the application object and this means no static QObjects? Apparently Qt itself doesn't respect that rule and also creates static objects that run code in the main thread no matter where the application object is created :/
I would consider this a Qt bug and expect it to crash all over the place.
EDIT: I missed that JKSH already mentioned this, but yeah, this seems to be the culprit.
-
I reproduced this on Windows and the message about timers comes from a destructor of a static QPixmapCache object that happens on the main() thread. That's not something the user's code does. It's in Qt's internals.
Right, so remember the rule that no QObject should outlive the application object and this means no static QObjects? Apparently Qt itself doesn't respect that rule and also creates static objects that run code in the main thread no matter where the application object is created :/
I would consider this a Qt bug and expect it to crash all over the place.
EDIT: I missed that JKSH already mentioned this, but yeah, this seems to be the culprit.
@Chris-Kawa said in QApplication in std::thread:
I reproduced this on Windows and the message about timers comes from a destructor of a static QPixmapCache object that happens on the main() thread. That's not something the user's code does. It's in Qt's internals.
Hm, interesting. Do you have a woboq location?
Right, so remember the rule that no QObject should outlive the application object and this means no static QObjects?
Apparently Qt itself doesn't respect that rule and also creates static objects that run code in the main thread no matter where the application object is created :/Yeah. Not living up to its own expectations it seems. :(
I would consider this a Qt bug and expect it to crash all over the place.
Me too, which is what I wrote somewhere upstairs - this should be fixed at the vendor side.
-
@Chris-Kawa said in QApplication in std::thread:
I reproduced this on Windows and the message about timers comes from a destructor of a static QPixmapCache object that happens on the main() thread. That's not something the user's code does. It's in Qt's internals.
Hm, interesting. Do you have a woboq location?
Right, so remember the rule that no QObject should outlive the application object and this means no static QObjects?
Apparently Qt itself doesn't respect that rule and also creates static objects that run code in the main thread no matter where the application object is created :/Yeah. Not living up to its own expectations it seems. :(
I would consider this a Qt bug and expect it to crash all over the place.
Me too, which is what I wrote somewhere upstairs - this should be fixed at the vendor side.
@kshegunov said in QApplication in std::thread:
Hm, interesting. Do you have a woboq location?
Instance declaration is here:
https://code.woboq.org/qt5/qtbase/src/gui/image/qpixmapcache.cpp.html#pm_cacheAnd here's Windows with MSVC crash callstack on exit:
1 QPMCache::~QPMCache qpixmapcache.cpp 269 2 ``anonymous namespace'::Q_QGS_pm_cache::innerFunction'::`2'::Holder::~Holder Qt5Guid 3 ``anonymous namespace'::Q_QGS_pm_cache::innerFunction'::`2'::`dynamic atexit destructor for 'holder'' Qt5Guid 4 initterm_e ucrtbased 5 initterm_e ucrtbased 6 initterm_e ucrtbased 7 execute_onexit_table ucrtbased 8 __scrt_dllmain_uninitialize_c utility.cpp 399 9 dllmain_crt_process_detach dll_dllmain.cpp 182 10 dllmain_crt_dispatch dll_dllmain.cpp 220 11 dllmain_dispatch dll_dllmain.cpp 293 12 _DllMainCRTStartup dll_dllmain.cpp 335 13 RtlActivateActivationContextUnsafeFast ntdll 14 LdrShutdownProcess ntdll 15 RtlExitUserProcess ntdll 16 FatalExit KERNEL32 17 wassert ucrtbased 18 wassert ucrtbased 19 exit ucrtbased 20 __scrt_common_main_seh exe_common.inl 297I used this simplified code:
int main(int argc, char *argv[]) { std::thread thr([](int argc, char *argv[]) { QApplication a(argc, argv); QPushButton btn("Push"); btn.show(); a.exec(); }, argc, argv); thr.join(); } -
@kshegunov said in QApplication in std::thread:
Hm, interesting. Do you have a woboq location?
Instance declaration is here:
https://code.woboq.org/qt5/qtbase/src/gui/image/qpixmapcache.cpp.html#pm_cacheAnd here's Windows with MSVC crash callstack on exit:
1 QPMCache::~QPMCache qpixmapcache.cpp 269 2 ``anonymous namespace'::Q_QGS_pm_cache::innerFunction'::`2'::Holder::~Holder Qt5Guid 3 ``anonymous namespace'::Q_QGS_pm_cache::innerFunction'::`2'::`dynamic atexit destructor for 'holder'' Qt5Guid 4 initterm_e ucrtbased 5 initterm_e ucrtbased 6 initterm_e ucrtbased 7 execute_onexit_table ucrtbased 8 __scrt_dllmain_uninitialize_c utility.cpp 399 9 dllmain_crt_process_detach dll_dllmain.cpp 182 10 dllmain_crt_dispatch dll_dllmain.cpp 220 11 dllmain_dispatch dll_dllmain.cpp 293 12 _DllMainCRTStartup dll_dllmain.cpp 335 13 RtlActivateActivationContextUnsafeFast ntdll 14 LdrShutdownProcess ntdll 15 RtlExitUserProcess ntdll 16 FatalExit KERNEL32 17 wassert ucrtbased 18 wassert ucrtbased 19 exit ucrtbased 20 __scrt_common_main_seh exe_common.inl 297I used this simplified code:
int main(int argc, char *argv[]) { std::thread thr([](int argc, char *argv[]) { QApplication a(argc, argv); QPushButton btn("Push"); btn.show(); a.exec(); }, argc, argv); thr.join(); }Yes, this is constructed appropriately, however the deallocation should've been tied to the
QCoreApplication::aboutToQuit. I doubt anyone is going to bother fixing it though, I'm not sure if it's not going to be discarded with "this is unsupported" even ... -
Yes, this is constructed appropriately, however the deallocation should've been tied to the
QCoreApplication::aboutToQuit. I doubt anyone is going to bother fixing it though, I'm not sure if it's not going to be discarded with "this is unsupported" even ...Good detective work, @Chris-Kawa!
I encountered this a few years ago but had forgotten most of the details.
@kshegunov said in Global static QPixmapCache in Qt internals:
Yes, this is constructed appropriately, however the deallocation should've been tied to the
QCoreApplication::aboutToQuit. I doubt anyone is going to bother fixing it though, I'm not sure if it's not going to be discarded with "this is unsupported" even ...Since a QPixmap requires a QGuiApplication, would a simple(?) and correct fix be to allocate the QPixmapCache in the QGuiApplication constructor, and deallocate it from the QGuiApplication destructor?
-
Good detective work, @Chris-Kawa!
I encountered this a few years ago but had forgotten most of the details.
@kshegunov said in Global static QPixmapCache in Qt internals:
Yes, this is constructed appropriately, however the deallocation should've been tied to the
QCoreApplication::aboutToQuit. I doubt anyone is going to bother fixing it though, I'm not sure if it's not going to be discarded with "this is unsupported" even ...Since a QPixmap requires a QGuiApplication, would a simple(?) and correct fix be to allocate the QPixmapCache in the QGuiApplication constructor, and deallocate it from the QGuiApplication destructor?
Possibly. Or it can be a pseudo-singleton (similarly to
QCoreApplication) and be initialized on demand in the instance retrieving function (dropping the global static that it currently uses). You could poke Thiago, but as written, I wouldn't hold my breath. -
Lifetime Qt Championwrote on 28 Apr 2021, 17:40 last edited by Christian Ehrlicher
There are some reports about such an issue:
https://bugreports.qt.io/browse/QTBUG-48709
https://bugreports.qt.io/browse/QTBUG-21807And it does not crash here for me on Linux and Windows (MSVC, debug-build) with 5.15.x
-
There are some reports about such an issue:
https://bugreports.qt.io/browse/QTBUG-48709
https://bugreports.qt.io/browse/QTBUG-21807And it does not crash here for me on Linux and Windows (MSVC, debug-build) with 5.15.x
@Christian-Ehrlicher said in Global static QPixmapCache in Qt internals:
And it does not crash here for me on Linux and Windows (MSVC, debug-build) with 5.15.x
We are talking about the QTimers from another thread message. JKSH, split the threads. The other stuff (the supposed crash) contines to befuddle me.
-
I also don't have a warning about the timer with the testcase on windows/msvc :)
-
wrote on 28 Apr 2021, 21:37 last edited by
We are talking about the QTimers from another thread message. JKSH, split the threads. The other stuff (the supposed crash) contines to befuddle me.
I don't know how exactly the crash in the original thread is connected with this. However, the crash and the message about timers are appearing together. They appear after any interaction with simple
QPushButton. UsingdeleteLater()as suggested by @JKSH solves the crash, but the message persists.@Christian-Ehrlicher said in Global static QPixmapCache in Qt internals:
And it does not crash here for me on Linux and Windows (MSVC, debug-build) with 5.15.x
To clarify: crash appears only when one tries to unload a library with
QApplicationinside. The library in my case is loaded bylua.exe, but I doubt it is lua-related problem. -
Possibly. Or it can be a pseudo-singleton (similarly to
QCoreApplication) and be initialized on demand in the instance retrieving function (dropping the global static that it currently uses). You could poke Thiago, but as written, I wouldn't hold my breath.wrote on 28 Apr 2021, 21:45 last edited by@kshegunov said in Global static QPixmapCache in Qt internals:
Possibly. Or it can be a pseudo-singleton (similarly to
QCoreApplication) and be initialized on demand in the instance retrieving function (dropping the global static that it currently uses). You could poke Thiago, but as written, I wouldn't hold my breath.That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
-
@kshegunov said in Global static QPixmapCache in Qt internals:
Possibly. Or it can be a pseudo-singleton (similarly to
QCoreApplication) and be initialized on demand in the instance retrieving function (dropping the global static that it currently uses). You could poke Thiago, but as written, I wouldn't hold my breath.That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
@jeremy_k said in Global static QPixmapCache in Qt internals:
That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
Adding non-virtual functions doesn't brake API or ABI compatibility. Also this is an internal member, any global getter function could do, it's not really necessary to expose it to the user.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
It's an internal class, I didn't intend to modify the
QPixmapCacheto begin with. (see the woboq link in Chris' post) -
@jeremy_k said in Global static QPixmapCache in Qt internals:
That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
Adding non-virtual functions doesn't brake API or ABI compatibility. Also this is an internal member, any global getter function could do, it's not really necessary to expose it to the user.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
It's an internal class, I didn't intend to modify the
QPixmapCacheto begin with. (see the woboq link in Chris' post)wrote on 29 Apr 2021, 02:54 last edited by@kshegunov said in Global static QPixmapCache in Qt internals:
@jeremy_k said in Global static QPixmapCache in Qt internals:
That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
Adding non-virtual functions doesn't brake API or ABI compatibility. Also this is an internal member, any global getter function could do, it's not really necessary to expose it to the user.
I had read it as a suggestion to introduce a static QPixmapCache::instance(), and make the currently static QPixmapCache member functions non-static. I autocompleted too much.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
It's an internal class, I didn't intend to modify the
QPixmapCacheto begin with. (see the woboq link in Chris' post)I saw, and if I interpreted correctly, the issue is that the global static QPixmapCache and its internal QObject based implementation will be destroyed from the C++ main thread when main() exits. The destruction of the internal implementation object could be removed from the public QPixmapCache destructor, but the question is where to destroy it while maintaining the current intended behavior. Making the internal object (or a wrapper) thread local in the gui thread solves destruction at a point where the cache can't see further use anyway.
-
@kshegunov said in Global static QPixmapCache in Qt internals:
@jeremy_k said in Global static QPixmapCache in Qt internals:
That sounds like a source and binary compatibility break, unless instance() is used from within the existing static functions.
Adding non-virtual functions doesn't brake API or ABI compatibility. Also this is an internal member, any global getter function could do, it's not really necessary to expose it to the user.
I had read it as a suggestion to introduce a static QPixmapCache::instance(), and make the currently static QPixmapCache member functions non-static. I autocompleted too much.
A thread_local version would be another solution, that could be implemented without changing any user source code. Keep the global static interface object for binary compatibility, and move the actual QObject-based implementation to thread_local storage for the gui thread.
The QPixmapCache documentation already says that the cache is only usable from the "application's main thread".
It's an internal class, I didn't intend to modify the
QPixmapCacheto begin with. (see the woboq link in Chris' post)I saw, and if I interpreted correctly, the issue is that the global static QPixmapCache and its internal QObject based implementation will be destroyed from the C++ main thread when main() exits. The destruction of the internal implementation object could be removed from the public QPixmapCache destructor, but the question is where to destroy it while maintaining the current intended behavior. Making the internal object (or a wrapper) thread local in the gui thread solves destruction at a point where the cache can't see further use anyway.
@jeremy_k said in Global static QPixmapCache in Qt internals:
I saw, and if I interpreted correctly, the issue is that the global static QPixmapCache and its internal QObject based implementation will be destroyed from the C++ main thread when main() exits.
Correct, but only with the allowance that we are talking about the
QPMCacheinstance (which is some internal class).The destruction of the internal implementation object could be removed from the public QPixmapCache destructor, but the question is where to destroy it while maintaining the current intended behavior.
As I wrote:
QCoreApplication::aboutToQuitis one possible such point. The problem with that solution is that it won't set the nullptr of the global pointer, which in turn is going to lead to a crash if the application object is recreated. It shouldn't get recreated, but I've seen code that relies on that (believe or not). With any API the first thing you get is hidden use cases, sadly.Making the internal object (or a wrapper) thread local in the gui thread solves destruction at a point where the cache can't see further use anyway.
I don't follow. The instance is created dynamically and on demand, and from some thread unknown at the point of declaration. How does specifying a thread local storage helps here, the pointer to the object is global (and I assume used from many a place)?
-
@jeremy_k said in Global static QPixmapCache in Qt internals:
I saw, and if I interpreted correctly, the issue is that the global static QPixmapCache and its internal QObject based implementation will be destroyed from the C++ main thread when main() exits.
Correct, but only with the allowance that we are talking about the
QPMCacheinstance (which is some internal class).The destruction of the internal implementation object could be removed from the public QPixmapCache destructor, but the question is where to destroy it while maintaining the current intended behavior.
As I wrote:
QCoreApplication::aboutToQuitis one possible such point. The problem with that solution is that it won't set the nullptr of the global pointer, which in turn is going to lead to a crash if the application object is recreated. It shouldn't get recreated, but I've seen code that relies on that (believe or not). With any API the first thing you get is hidden use cases, sadly.Making the internal object (or a wrapper) thread local in the gui thread solves destruction at a point where the cache can't see further use anyway.
I don't follow. The instance is created dynamically and on demand, and from some thread unknown at the point of declaration. How does specifying a thread local storage helps here, the pointer to the object is global (and I assume used from many a place)?
wrote on 29 Apr 2021, 18:10 last edited by@kshegunov said in Global static QPixmapCache in Qt internals:
@jeremy_k said in Global static QPixmapCache in Qt internals:
I saw, and if I interpreted correctly, the issue is that the global static QPixmapCache and its internal QObject based implementation will be destroyed from the C++ main thread when main() exits.
Correct, but only with the allowance that we are talking about the
QPMCacheinstance (which is some internal class).Yes. We seem to be talking around the same point.
The destruction of the internal implementation object could be removed from the public QPixmapCache destructor, but the question is where to destroy it while maintaining the current intended behavior.
As I wrote:
QCoreApplication::aboutToQuitis one possible such point. The problem with that solution is that it won't set the nullptr of the global pointer, which in turn is going to lead to a crash if the application object is recreated. It shouldn't get recreated, but I've seen code that relies on that (believe or not). With any API the first thing you get is hidden use cases, sadly.Making the internal object (or a wrapper) thread local in the gui thread solves destruction at a point where the cache can't see further use anyway.
I don't follow. The instance is created dynamically and on demand, and from some thread unknown at the point of declaration. How does specifying a thread local storage helps here, the pointer to the object is global (and I assume used from many a place)?
Using QCoreApplication::aboutToQuit would change the behavior for applications that repeatedly instantiate and destroy the application instance, and it would add an opportunity to make a mistake for applications that don't use QCoreApplication::exec().
Using a thread local object keeps this into RAII territory. The only difference from the current global static is that destruction happens in the relevant thread rather than in the main() thread.
How does the cache managing object tell that it is in the gui thread? If the first application instance must be created before cache use, QThread::currentThread()->threadId() == QCoreApplication::instance()->thread()->threadId() could work. I don't know if creating the application first is currently required.
17/34