https://bugs.kde.org/show_bug.cgi?id=481045
--- Comment #4 from Jakob Petsovits <jpe...@petsovits.com> --- It looks like this kind of stuff should be prevented by the KQuickConfigModule destructor, which seems to unload the QML rootObject: https://invent.kde.org/frameworks/kcmutils/-/blob/master/src/qml/kquickconfigmodule.cpp?ref_type=heads#L71 If my C++ isn't totally off, the destructor order should go like: 1. ~PowerKCM() - no-op 2. ~KQuickManagedConfigModule() - deletes KQuickManagedConfigModulePrivate, which only holds non-owning pointers to KCoreConfigSkeleton objects 3. ~KQuickConfigModule() - unloading QML, see above 4. ~KAbstractConfigModule() - deletes KAbstractConfigModulePrivate, which holds plugin metadata and other only tangentially related stuff 5. ~QObject() - deletes children of PowerKCM, i.e. the various settings and model objects I don't yet see what exactly is going wrong there. What I'm wondering is where the QV4::QQmlContextWrapper::lookupScopeObjectProperty call is coming from in that backtrace, we see a few "???" but I'd be super curious if this happens inside this whole destructor inheritance chain or is called externally somewhere. -- You are receiving this mail because: You are watching all bug changes.
