Summary: | Kirigami Gallery crashed in ~DelegateCache() | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | ratijas <me> |
Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | crash | CC: | notmart |
Priority: | NOR | Keywords: | qt6 |
Version: | Master | ||
Target Milestone: | Not decided | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
ratijas
2023-08-21 18:58:42 UTC
Seems like it affects both KF5 (Qt 5.15) and KF6 (Qt 6.5) versions of Kirigami. Stacktrace is quite similar, almost identical. The offending page is managed by PagePool and PagePoolAction. If I manually clear() the PagePool before quitting app, it won't crash. It all comes down to the PagePool presumably not doing proper clean-up on it own destruction. DelegateRecycler stores its component and instantiated items in a DelegateCache, but the cache is supposed to be empty on exit, because every delegate creation (ref) should be balanced by a destruction (deref). Cleaning up items after shutdown (during __run_exit_handlers) is a very questionable activity, as destructors (like in case of QQuickButton) might try to access null qApp resources. However, why do those item delegates not get destroyed along with their associated QQmlEngine? Because they have C++ ownership, they do not have any parent QObject, and nothing connects them with their engine's lifecycle. Proposed upstream fix for some types that don't particularly like the idea of running their destructors after main(): https://codereview.qt-project.org/c/qt/qtdeclarative/+/498195 DelegateRecycler was removed in https://invent.kde.org/frameworks/kirigami/-/commit/fab45ed502108a46277223e266920b7de6fef8e5 |