Review Request 122105: Fix KgDifficulty saving on app close

[Albert Astals Cid]

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
> crash.
> 
> > 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
> http://www.davidfaure.fr/2015/ksharedconfig_in_global_object.cpp
> 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?


See 
http://quickgit.kde.org/?p=libkdegames.git&a=blob&h=b94cce00ef338cdfd3224e3542074b699ead0b29&hb=63855d630c928e46554885f6d022d0091dbe252b&f=kgdifficulty.cpp

It has a

K_GLOBAL_STATIC(KgDifficulty, g_difficulty)

and a 

KConfigGroup cg(KGlobal::config(), "KgDifficulty");
cg.writeEntry("Level", currentLevel()->key());

in KgDifficulty destructor.

And it did work :D

Cheers,
  Albert