[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Problem with KCompTreeNode on Windows (or: destruction order of static objects?)
From:       Milian Wolff <mail () milianw ! de>
Date:       2013-12-04 15:36:12
Message-ID: 2163115.GQ8o8SuM9j () milian-kdab2
[Download RAW message or body]

On Wednesday 04 December 2013 16:01:03 Frank Reininghaus wrote:
> Hi,
> 
> 2013/11/30 Kevin Funk:
> > Hey guys,
> > 
> > My recent attempts to make KDevelop shine on Windows revealed some odd
> > behaviour inside kdelibs.
> > 
> > I need some help in order to find the right approach to fix an at least 3
> > year old bug [1] ultimately caused by the use of a static member object
> > in the KCompTreeNode class (kcompletion.h) in kdelibs. Please see the
> > attached bug report [2].
> > 
> > Note that the error *only shows up on Windows*, on Linux we don't have
> > this
> > problem. I'll try to explain what's wrong in this mail.
> > 
> > The actual issue:
> > - KDevelop running:
> > - We have an instance of KateGlobal owned by KateFactory,
> > 
> >   a plugin loaded by KDevelop
> > 
> > - Some descendant of KateGlobal (KateCmd) owns a KCompTreeNode instance
> > - KCompTreeNode uses a custom allocator for creating/deleting instances
> > 
> >   of itself, holds a static member of type KZoneAllocactor for that
> > 
> > - KZoneAllocator holds the memory for all the instantiated KCompTreeNodes
> > 
> > So we have the following object ownership (some levels omitted):
> > - KateFactory
> > 
> >     KateGlobal
> >     
> >       KCompTreeNode
> >       
> >         KZoneAllocator (static)
> > 
> > When closing KDevelop *under Linux*:
> > - ~KateFactory, via QObjectCleanupHandler during __run_exit_handlers
> > (glibc)> 
> >     ~KateGlobal, via call to KateGlobal::decRef()
> >     
> >       ~KCompTreeNode
> > 
> > - ~KZoneAllocator, during __cxa__finalize (glibc)
> > 
> > The order is fine in this case. No segfaults.
> > 
> > However, on Windows the destruction order is different (and I cannot
> > really
> > explain why). When closing KDevelop *under Windows*:
> > - ~KZoneAllocator is called first, via
> > 
> >         "kdeui.dll!`dynamic atexit destructor for
> >         'KCompTreeNode::alloc''()"
> > 
> > - ~KateFactory, via QObjectCleanupHandler
> > 
> >     ~KateGlobal
> >     
> >       Call to KCompTreeNode::removeItem()
> > 
> > => Crash because memory for the KCompTreeNode instances was already freed
> > 
> >    by ~KZoneAllocator
> > 
> > I wonder how to fix that:
> > The easiest solution obviously: Get rid off the custom allocator in
> > KCompTreeNode. Having a class owning its custom allocator is just plain
> > wrong, right? But removing that probably has performance impacts. (Does
> > anyone have benchmarks here?)
> 
> well, having a custom allocator may have some benefits. I guess that
> KCompletion uses one to ensure that all KCompTreeNodes are close to
> each other in memory and thus to reduce cache misses? I don't know how
> much dropping the custom allocator would affect the performance, one
> would have to do some benchmarking with typical KCompletion use cases.

I agree that it might be a good performance improvement. But I want to note 
neither KDevelop nore Kate uses this technique for its code completion in the 
editor. And we probably have much more completion tree nodes than a usual 
KCompletion user. I just mention this to show that removing this performance 
improvement should not kill the performance, rather decrease it slightly.

> > Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't help
> > either. I get the same destruction order + crash with that on Windows.
> > 
> > Dynamic allocation inside KCompTreeNode doesn't work either, because
> > KZoneAllocator needs to be there *before* the first KCompTreeNode is
> > created and needs to there *until* the last one has been destroyed.
> > 
> > Any ideas?
> 
> Well, here is one idea (untested): use a
> QSharedPointer<KZoneAllocator> to ensure that the KZoneAllocator is
> not destroyed before the last KCompletion instance using it.
> 
> Replace
> 
> static KZoneAllocator alloc;
> 
> in KCompTreeNode by
> 
> static QSharedPointer<KZoneAllocator> alloc;
> 
> and, in kcompletion.cpp,
> 
> KZoneAllocator KCompTreeNode::alloc(8192);
> 
> by
> 
> QSharedPointer<KZoneAllocator> KCompTreeNode::alloc;
> 
> In KCompTreeNode's operator new/delete, replace "alloc." by "alloc->".
> 
> Furthermore, add a QSharedPointer<KZoneAllocator> member to
> KCompletionPrivate. In KCompletionPrivate's constructor, first check
> if KCompTreeNode::alloc isNull(), initialize it if that is not the
> case, and then copy "alloc" to the new member.
> 
> I think that this might work, and it might also improve application
> start-up time because the KZoneAllocator would only be initialized on
> first use of a KCompletion object.

Yes, that might work. Kevin, could you try it out?

Bye
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]