Qt5 lighthouse plugins and clean up on exit

[Holger Freyther]

Hi,

it appears to me that the EventDispatcher and FontDatabase are leaked
on exit (even on the XCB plugin). Is there any plan to resolve that?

On a different and more directFB specific note, the input handling
appears in a thread and this thread is only torn down in the dtor of
the QDirectFBIntegration class. This can lead to the effect that some
more events have been posted to the QApplication event queue. Could we
add a function to the QPlatformIntegration to stop processing events
before we start to destruct it, alternatively one could just flush
the queue on exit?

comments

h

[Holger Freyther]

Post by Holger Freyther
Hi,
it appears to me that the EventDispatcher and FontDatabase are leaked
on exit (even on the XCB plugin). Is there any plan to resolve that?

One example that got introduced when Qt Quick2 was imported into the
qtbase repository.

operator new(unsigned int) (vg_replace_malloc.c:255)
QUnifiedTimer::instance(bool) (qabstractanimation.cpp:183)
QAnimationDriver::~QAnimationDriver() (qabstractanimation.cpp:461)
QDefaultAnimationDriver::~QDefaultAnimationDriver()
QUnifiedTimer::~QUnifiedTimer()
QUnifiedTimer::~QUnifiedTimer() (qabstractanimation_p.h:146)
void qThreadStorage_deleteData<QUnifiedTimer>(void*, QUnifiedTimer**)
QThreadStorage<QUnifiedTimer*>::deleteData(void*) (qthreadstorage.h:140)
QThreadStorageData::finish(void**) (qthreadstorage.cpp:203)
QCoreApplicationPrivate::cleanupThreadData() (qcoreapplication.cpp:377)
QGuiApplicationPrivate::~QGuiApplicationPrivate() (qguiap....cpp:406)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:208)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:212)
QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*)
...

the easiest fix would be:
QAnimationDriver::~QAnimationDriver()
{
- QUnifiedTimer *timer = QUnifiedTimer::instance(true);
- if (timer->canUninstallAnimationDriver(this))
+ QUnifiedTimer *timer = QUnifiedTimer::instance(false);
+ if (time && timer->canUninstallAnimationDriver(this))
uninstall();
}

ask the 'factory' to not create an instance. I could only trace this
code back to import of Qt Quick2 (anyone has nice git grafts?). Can
we get a 'clean' shutdown into the goals of Qt5, even if it is only
done in a debug build?


cheers
holger

[Samuel Rødal]

Post by Holger Freyther

Post by Holger Freyther
Hi,
it appears to me that the EventDispatcher and FontDatabase are leaked
on exit (even on the XCB plugin). Is there any plan to resolve that?

One example that got introduced when Qt Quick2 was imported into the
qtbase repository.
operator new(unsigned int) (vg_replace_malloc.c:255)
QUnifiedTimer::instance(bool) (qabstractanimation.cpp:183)
QAnimationDriver::~QAnimationDriver() (qabstractanimation.cpp:461)
QDefaultAnimationDriver::~QDefaultAnimationDriver()
QUnifiedTimer::~QUnifiedTimer()
QUnifiedTimer::~QUnifiedTimer() (qabstractanimation_p.h:146)
void qThreadStorage_deleteData<QUnifiedTimer>(void*, QUnifiedTimer**)
QThreadStorage<QUnifiedTimer*>::deleteData(void*) (qthreadstorage.h:140)
QThreadStorageData::finish(void**) (qthreadstorage.cpp:203)
QCoreApplicationPrivate::cleanupThreadData() (qcoreapplication.cpp:377)
QGuiApplicationPrivate::~QGuiApplicationPrivate() (qguiap....cpp:406)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:208)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:212)
QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*)
...
QAnimationDriver::~QAnimationDriver()
{
- QUnifiedTimer *timer = QUnifiedTimer::instance(true);
- if (timer->canUninstallAnimationDriver(this))
+ QUnifiedTimer *timer = QUnifiedTimer::instance(false);
+ if (time&& timer->canUninstallAnimationDriver(this))
uninstall();
}
ask the 'factory' to not create an instance. I could only trace this
code back to import of Qt Quick2 (anyone has nice git grafts?). Can
we get a 'clean' shutdown into the goals of Qt5, even if it is only
done in a debug build?

Clean shutdown is something that's needed, but that hasn't been
prioritized as much as certain more 'visible' issues so far. Could you
create tasks for all the issues you see? Maybe we should label all Qt 5
related issues with #qt5 from now on. There's
https://bugreports.qt.nokia.com/browse/QTBUG-20080 but it seems
impractical add all bug reports as sub-tasks there (it's mainly meant
for todos, features, and required API changes). Although if it's a more
generic sub-task like "Clean shutdown" that could work, but we still
want to track each issue individually (through sub-sub-tasks?).

--
Samuel

[Holger Freyther]

Post by Samuel Rødal
There's
https://bugreports.qt.nokia.com/browse/QTBUG-20080 but it seems
impractical add all bug reports as sub-tasks there (it's mainly meant
for todos, features, and required API changes). Although if it's a more
generic sub-task like "Clean shutdown" that could work, but we still
want to track each issue individually (through sub-sub-tasks?).

https://bugreports.qt.nokia.com/browse/QTBUG-21805

I created the above bug report with some specific sub-tasks that I am
aware of (there is maybe more).