During QCoreApplication initialization, we create the main thread's event
dispatcher, which for a GUI app happens via QGuiApplicationPrivate's
createEventDispatcher() override. This in turn relies on the platform
integration to create the event dispatcher, but to do that it needs to
create the platform integration first. And this might result in calling
APIs that themselves initialize the main thread event dispatcher, such
as QEventLoop, which non-lazily creates an event dispatcher for the thread.
We already had a check to catch the platform integration setting the
QCoreApplictionPrivate::eventDispatcher member, but not anything for
checking the current thread data.
On macOS this resulted in a leak of QEventDispatcherUNIX because
QCocoaDrag contained a QEventLoop member. We now track the event
loop temproarily via a pointer instead, like we do in other places.
An alternative fix would be to defer the initialization of QCocoaDrag
until QCocoaIntegration::drag() is called, but that would run the
risk of something calling the function during platform initialization
and we'd be back to the same problem.
It's unclear why QEventLoop is not lazily ensuring the event dispatcher,
and this might be a wider fix for similar issues.
Pick-to: 6.5
Change-Id: I643010ddb09945936ce9b0b94de0df96f6fe218f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
4160817050