Review Request 122105: Fix KgDifficulty saving on app close

[David Faure]

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?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5