Review Request 122232: KConfig: fix using KSharedConfig in global object destructor.

[David Faure]

> On Jan. 27, 2015, 6:31 a.m., Matthew Dawson wrote:
> > Sorry, I just discovered an issue with this change as is.  If the global object is created before KConfig's Global object, a seg fault develops.  In this case, KConfig's global is created first avoiding the pain.  However, commenting out the noted line causes a seg fault in the tests.
> > 
> > I don't think we can assume people will know to create appropriate KConfig objects, so I'd like to avoid relying on this in the test to pass.  I'm not sure how we can force the creation of the global ahead of time.  My best thought would be some sort of global pointer to the QStringList, combined with some atomic pointer operations to create it.  Thoughts?
> > 
> > Otherwise, everything looked go to me.
> 
> David Faure wrote:
>     The problem is not the order of construction in itself (construction is on demand), but the order of destruction (which is reverse to the order of construction, at least on linux). I know that it crashes without this line, but it does that in kdelibs4 too:
>     
>     Fatal Error: Accessed global static 'KGlobalPrivate *globalData()' after destruction. Defined at kde/kdelibs/kdecore/kernel/kglobal.cpp:128
>     
>     Therefore I don't consider this a real problem. This crash or assert comes from relying on the order of destruction, which one is not supposed to do. In practice most apps will use KConfig soon after creating the app anyway, for their mainwindow, which is why we didn't have a big problem with this.
>     
>     If we really want to fix this, however, Q_CONSTRUCTOR_FUNCTION(someFunc) (in ksharedconfig.cpp) comes to mind. That would allow to automate exactly what the line in the test does, calling openConfig right after the qapp is created. I'm just not sure if this is a good idea ;)
>     Hmm, I'm slowly warming up to the idea, seeing that it doesn't actually create a file if the app doesn't end up using KConfig at all (but just links to the lib indirectly). Let me try it out.

I mean Q_COREAPP_STARTUP_FUNCTION.
Q_CONSTRUCTOR_FUNCTION is too early, no qApp yet.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122232/#review74802
-----------------------------------------------------------


On Jan. 26, 2015, 8:11 a.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122232/
> -----------------------------------------------------------
> 
> (Updated Jan. 26, 2015, 8:11 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> -------
> 
> kconfig_in_global_object.cpp comes from kdelibs4support
> (after porting to Q_GLOBAL_STATIC)
> 
> ksharedconfig_in_global_object.cpp is new (but works with kdelibs4)
> and reproduces Albert's KgDifficulty testcase.
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt b91f754b705fc87bb8b729bea72fbb5f7d427ace 
>   autotests/kconfig_in_global_object.cpp PRE-CREATION 
>   autotests/ksharedconfig_in_global_object.cpp PRE-CREATION 
>   src/core/kconfig.cpp 782e9714521234a3e3d8f3a788967e5c9a40f38a 
> 
> Diff: https://git.reviewboard.kde.org/r/122232/diff/
> 
> 
> Testing
> -------
> 
> Both tests pass and the QCoreApplication::arguments warning (because called after qApp is destroyed) is gone.
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150127/58bfbeea/attachment.html>