Review Request 122105: Fix KgDifficulty saving on app close
Albert Astals Cid
aacid at kde.org
Mon Jan 19 20:43:41 UTC 2015
El Dilluns, 19 de gener de 2015, a les 21:15:42, David Faure va escriure:
> On Monday 19 January 2015 19:54:46 Albert Astals Cid wrote:
> > El Dilluns, 19 de gener de 2015, a les 09:02:07, David Faure va escriure:
> > > On Saturday 17 January 2015 21:48:29 Albert Astals Cid wrote:
> > > > KF5 people: Is this something worth mentioning on the porting notes or
> > > > using KSharedConfig::openConfig from a static destructor is a bit of a
> > > > corner case anyway?
> > >
> > > It's not the first time we hit this (IIRC), so yeah, it's definitely
> > > worth
> > > mentionning in the porting notes and in the KSharedConfig documentation.
> > >
> > > Or maybe we can look into fixing this somehow? If just the app name is
> > > needed, we could keep a copy of it ....
> > I had a quick look, but could not find anywhere to copy it, what's going
> > to
> > live more time that my statics? I actually don't even understand how this
> > used to work :D
> OK I had a look, and I discovered that
> * there are related unittests in kdelibs4support, I am moving (copying) them
> to kconfig (without deprecated stuff).
> * there are a number of issues here
> 1) KConfig::mainConfigName uses QCoreApplication::arguments() to check for
> --config. Doing this after qApp is destroyed leads to a runtime waning.
> KApplication was storing this in its componentdata. Even if we didn't have
> the issue described below in kdelibs4, I'm not sure we ever tested that
> using KConfig in a global-object-destructor worked in combination with the
> very- rarely-used --config command-line-option....
> 2) KConfig::mainConfigName then uses its own global object,
> globalMainConfigName(), which might be already deleted as well, leading to a
> > I actually don't even understand how this used to work :D
> Well, it didn't. I just tried my testcase in kdelibs4, and I got this:
> Fatal Error: Accessed global static 'KGlobalPrivate *globalData()' after
> destruction. Defined at kdelibs/kdecore/kernel/kglobal.cpp:128
> Here's the testcase
> Fails with both kdelibs4 and kconfig5, everything's consistent :-)
> So the real question is: what did kgdifficulty really do in the kdelibs4
> world, that worked?
It has a
KConfigGroup cg(KGlobal::config(), "KgDifficulty");
in KgDifficulty destructor.
And it did work :D
More information about the Kde-frameworks-devel